From rgiulietti at openjdk.org  Sun Sep  1 10:03:18 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 1 Sep 2024 10:03:18 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v3]
In-Reply-To: <0o2xYGSl7InSp0WvSNE4UYhSg5jdsIM9pF8D0wAxrl8=.0cc9a8b5-f25c-4b65-a983-9f7e9b370701@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <0o2xYGSl7InSp0WvSNE4UYhSg5jdsIM9pF8D0wAxrl8=.0cc9a8b5-f25c-4b65-a983-9f7e9b370701@github.com>
Message-ID: <A7sY9ctJHm1ZDjv7WAvt2Z4Nsp-_nLGbO_sCQr1oYiA=.5d00fcba-a41a-40bc-8797-834aa500a7d5@github.com>

On Sat, 31 Aug 2024 15:05:58 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tests changes

@fabioromano1 I'll have a look at your PR in the coming week.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2323265157

From duke at openjdk.org  Sun Sep  1 16:32:00 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 1 Sep 2024 16:32:00 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v4]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <j5OFnbrBkNWElnNhduuF-Q66chcQX-kAPJDMIL4McO0=.4fb57d80-91f1-447e-95dd-e3f22364d14d@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

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

  Code more clear

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/cac34ef9..9231c600

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

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

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

From jwaters at openjdk.org  Sun Sep  1 16:33:24 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 1 Sep 2024 16:33:24 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <sl8l59-K_dTtCIlRlfwnD09JBWLYUiivU2V6hN-TSz0=.5c7e95af-4484-4a5f-8f14-f3b2e6cb5da0@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

This does make me wonder: What if the new method for checking if the VM was statically linked was inlined? Then the problem comes back yet again as the object files need to be recompiled once more. This is possible if Link Time Optimization is switched on, and I don't like the implication that LTO might be removed as a result just to make this work

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

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2323416932

From duke at openjdk.org  Sun Sep  1 17:17:19 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sun, 1 Sep 2024 17:17:19 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, 
 ConstantDesc) [v2]
In-Reply-To: <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
 <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
Message-ID: <JgXHjvrLpvxJAxxTnzSByqsal3VPiL3mF6yfToUJWBw=.0c5d6b85-6729-4f79-81e8-d369938ad080@github.com>

On Thu, 29 Aug 2024 21:46:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and confusing. Users should almost always use `loadConstant(ConstantDesc)` for optimized instructions, or use specific factories `iconst_0` etc. or `bipush` with arguments or `LoadConstantInstruction.of` if they want to specify the exact type of LDC opcode.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move bipush and sipush fix from Opcode cleanup to this patch

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

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

PR Review: https://git.openjdk.org/jdk/pull/20779#pullrequestreview-2274458870

From swen at openjdk.org  Sun Sep  1 23:34:57 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 1 Sep 2024 23:34:57 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
Message-ID: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>

TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.

The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.

* baseline

@ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
  @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
  @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
  @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large


* current

@ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large

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

Commit messages:
 - remove benchmark incorrect comments
 - use Class#isPrimitive
 - Reorder by frequency
 - Suggestions from @ExE-Boss
 - Update src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - move benchmark to classfile
 - Merge remote-tracking branch 'upstream/master' into optim_type_kind_from
 - add benchmark
 - fix build test error
 - optimize TypeKind#from
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b840b130...91d247af

Changes: https://git.openjdk.org/jdk/pull/20762/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339358
  Stats: 123 lines in 3 files changed: 116 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20762/head:pull/20762

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

From swen at openjdk.org  Sun Sep  1 23:34:57 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 1 Sep 2024 23:34:57 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
In-Reply-To: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
Message-ID: <1ar6iQ4_YHbn5NR2MVueRB3TxlGafcfvAaIBSj59-m8=.4b7c2bd8-e891-4426-9716-06063a53bb71@github.com>

On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.
> 
> The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.
> 
> * baseline
> 
> @ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
>   @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>   @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
>   @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large
> 
> 
> * current
> 
> @ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large

Below are the performance numbers running on a MacBook M1

## 1. TieredStopAtLevel=1

### 1.1 Script

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

# baseline
git checkout 990958a8724c88e7eeb4c0af7db4c937c51ffffe
make test TEST="micro:java.lang.constant.TypeKindFrom" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout a29acc54f2b13067cd4899d46f9d29c4e517aed0
make test TEST="micro:java.lang.constant.TypeKindFrom" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"


### 1.2 Performance Numbers


-# baseline
-Benchmark                         (typeName)  Mode  Cnt    Score   Error  Units
-TypeKindFrom.fromClass                     B  avgt    9  444.221 ? 9.995  ns/op
-TypeKindFrom.fromClass                     C  avgt    9  442.828 ? 3.071  ns/op
-TypeKindFrom.fromClass                     Z  avgt    9  432.887 ? 1.750  ns/op
-TypeKindFrom.fromClass                     S  avgt    9  436.567 ? 2.582  ns/op
-TypeKindFrom.fromClass                     I  avgt    9  432.613 ? 3.427  ns/op
-TypeKindFrom.fromClass                     F  avgt    9  448.737 ? 2.134  ns/op
-TypeKindFrom.fromClass                     J  avgt    9  433.297 ? 2.909  ns/op
-TypeKindFrom.fromClass                     D  avgt    9  452.180 ? 1.926  ns/op
-TypeKindFrom.fromClass                     V  avgt    9  454.183 ? 3.541  ns/op
-TypeKindFrom.fromClass      java.lang.Object  avgt    9  148.701 ? 0.141  ns/op
-TypeKindFrom.fromClassDesc                 B  avgt    9  164.980 ? 0.412  ns/op
-TypeKindFrom.fromClassDesc                 C  avgt    9  165.348 ? 0.638  ns/op
-TypeKindFrom.fromClassDesc                 Z  avgt    9  164.978 ? 0.527  ns/op
-TypeKindFrom.fromClassDesc                 S  avgt    9  164.685 ? 0.909  ns/op
-TypeKindFrom.fromClassDesc                 I  avgt    9  164.591 ? 0.211  ns/op
-TypeKindFrom.fromClassDesc                 F  avgt    9  164.399 ? 0.364  ns/op
-TypeKindFrom.fromClassDesc                 J  avgt    9  164.907 ? 0.970  ns/op
-TypeKindFrom.fromClassDesc                 D  avgt    9  164.221 ? 1.483  ns/op
-TypeKindFrom.fromClassDesc                 V  avgt    9  164.275 ? 0.650  ns/op
-TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  164.773 ? 0.777  ns/op

+# current
+Benchmark                         (typeName)  Mode  Cnt    Score   Error  Units
+TypeKindFrom.fromClass                     B  avgt    9   82.000 ? 1.855  ns/op
+TypeKindFrom.fromClass                     C  avgt    9   83.849 ? 0.757  ns/op
+TypeKindFrom.fromClass                     Z  avgt    9   75.043 ? 0.567  ns/op
+TypeKindFrom.fromClass                     S  avgt    9   91.629 ? 0.460  ns/op
+TypeKindFrom.fromClass                     I  avgt    9   87.585 ? 0.441  ns/op
+TypeKindFrom.fromClass                     F  avgt    9   96.923 ? 0.680  ns/op
+TypeKindFrom.fromClass                     J  avgt    9   90.674 ? 0.178  ns/op
+TypeKindFrom.fromClass                     D  avgt    9  103.853 ? 0.359  ns/op
+TypeKindFrom.fromClass                     V  avgt    9  104.074 ? 1.012  ns/op
+TypeKindFrom.fromClass      java.lang.Object  avgt    9  116.578 ? 0.865  ns/op
+TypeKindFrom.fromClassDesc                 B  avgt    9  116.473 ? 0.252  ns/op
+TypeKindFrom.fromClassDesc                 C  avgt    9  116.450 ? 0.915  ns/op
+TypeKindFrom.fromClassDesc                 Z  avgt    9  116.832 ? 0.389  ns/op
+TypeKindFrom.fromClassDesc                 S  avgt    9  118.954 ? 3.664  ns/op
+TypeKindFrom.fromClassDesc                 I  avgt    9  116.153 ? 0.302  ns/op
+TypeKindFrom.fromClassDesc                 F  avgt    9  116.076 ? 0.400  ns/op
+TypeKindFrom.fromClassDesc                 J  avgt    9  116.204 ? 1.159  ns/op
+TypeKindFrom.fromClassDesc                 D  avgt    9  116.235 ? 0.605  ns/op
+TypeKindFrom.fromClassDesc                 V  avgt    9  116.227 ? 1.319  ns/op
+TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  116.466 ? 0.929  ns/op


|   | typeName | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| TypeKindFrom.fromClass | B | 444.221 | 82.000 | 441.73% |
| TypeKindFrom.fromClass | C | 442.828 | 83.849 | 428.13% |
| TypeKindFrom.fromClass | Z | 432.887 | 75.043 | 476.85% |
| TypeKindFrom.fromClass | S | 436.567 | 91.629 | 376.45% |
| TypeKindFrom.fromClass | I | 432.613 | 87.585 | 393.94% |
| TypeKindFrom.fromClass | F | 448.737 | 96.923 | 362.98% |
| TypeKindFrom.fromClass | J | 433.297 | 90.674 | 377.86% |
| TypeKindFrom.fromClass | D | 452.180 | 103.853 | 335.40% |
| TypeKindFrom.fromClass | V | 454.183 | 104.074 | 336.40% |
| TypeKindFrom.fromClass | java.lang.Object | 148.701 | 116.578 | 27.55% |
| TypeKindFrom.fromClassDesc | B | 164.980 | 116.473 | 41.65% |
| TypeKindFrom.fromClassDesc | C | 165.348 | 116.450 | 41.99% |
| TypeKindFrom.fromClassDesc | Z | 164.978 | 116.832 | 41.21% |
| TypeKindFrom.fromClassDesc | S | 164.685 | 118.954 | 38.44% |
| TypeKindFrom.fromClassDesc | I | 164.591 | 116.153 | 41.70% |
| TypeKindFrom.fromClassDesc | F | 164.399 | 116.076 | 41.63% |
| TypeKindFrom.fromClassDesc | J | 164.907 | 116.204 | 41.91% |
| TypeKindFrom.fromClassDesc | D | 164.221 | 116.235 | 41.28% |
| TypeKindFrom.fromClassDesc | V | 164.275 | 116.227 | 41.34% |
| TypeKindFrom.fromClassDesc | java.lang.Object | 164.773 | 116.466 | 41.48% |


## 2. Non-JVM Options

### 2.1 Script

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

# baseline
git checkout 990958a8724c88e7eeb4c0af7db4c937c51ffffe
make test TEST="micro:java.lang.constant.TypeKindFrom"

# current
git checkout a29acc54f2b13067cd4899d46f9d29c4e517aed0
make test TEST="micro:java.lang.constant.TypeKindFrom"


## 2.2 Performance Numbers

-# baseline
-Benchmark                         (typeName)  Mode  Cnt  Score   Error  Units
-TypeKindFrom.fromClass                     B  avgt    9  1.563 ? 0.004  ns/op
-TypeKindFrom.fromClass                     C  avgt    9  1.716 ? 0.009  ns/op
-TypeKindFrom.fromClass                     Z  avgt    9  1.252 ? 0.002  ns/op
-TypeKindFrom.fromClass                     S  avgt    9  1.410 ? 0.015  ns/op
-TypeKindFrom.fromClass                     I  avgt    9  1.268 ? 0.017  ns/op
-TypeKindFrom.fromClass                     F  avgt    9  1.874 ? 0.013  ns/op
-TypeKindFrom.fromClass                     J  avgt    9  1.096 ? 0.006  ns/op
-TypeKindFrom.fromClass                     D  avgt    9  2.184 ? 0.018  ns/op
-TypeKindFrom.fromClass                     V  avgt    9  2.183 ? 0.010  ns/op
-TypeKindFrom.fromClass      java.lang.Object  avgt    9  0.677 ? 0.061  ns/op
-TypeKindFrom.fromClassDesc                 B  avgt    9  1.010 ? 0.003  ns/op
-TypeKindFrom.fromClassDesc                 C  avgt    9  1.081 ? 0.001  ns/op
-TypeKindFrom.fromClassDesc                 Z  avgt    9  1.082 ? 0.091  ns/op
-TypeKindFrom.fromClassDesc                 S  avgt    9  1.010 ? 0.004  ns/op
-TypeKindFrom.fromClassDesc                 I  avgt    9  1.010 ? 0.004  ns/op
-TypeKindFrom.fromClassDesc                 F  avgt    9  1.010 ? 0.004  ns/op
-TypeKindFrom.fromClassDesc                 J  avgt    9  1.049 ? 0.091  ns/op
-TypeKindFrom.fromClassDesc                 D  avgt    9  1.012 ? 0.010  ns/op
-TypeKindFrom.fromClassDesc                 V  avgt    9  1.010 ? 0.003  ns/op
-TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  1.011 ? 0.003  ns/op

+# current
+Benchmark                         (typeName)  Mode  Cnt  Score   Error  Units
+TypeKindFrom.fromClass                     B  avgt    9  0.646 ? 0.050  ns/op
+TypeKindFrom.fromClass                     C  avgt    9  0.786 ? 0.016  ns/op
+TypeKindFrom.fromClass                     Z  avgt    9  0.588 ? 0.092  ns/op
+TypeKindFrom.fromClass                     S  avgt    9  1.245 ? 0.002  ns/op
+TypeKindFrom.fromClass                     I  avgt    9  0.934 ? 0.002  ns/op
+TypeKindFrom.fromClass                     F  avgt    9  1.402 ? 0.004  ns/op
+TypeKindFrom.fromClass                     J  avgt    9  1.091 ? 0.004  ns/op
+TypeKindFrom.fromClass                     D  avgt    9  1.713 ? 0.004  ns/op
+TypeKindFrom.fromClass                     V  avgt    9  1.714 ? 0.004  ns/op
+TypeKindFrom.fromClass      java.lang.Object  avgt    9  1.713 ? 0.006  ns/op
+TypeKindFrom.fromClassDesc                 B  avgt    9  1.735 ? 0.052  ns/op
+TypeKindFrom.fromClassDesc                 C  avgt    9  1.712 ? 0.004  ns/op
+TypeKindFrom.fromClassDesc                 Z  avgt    9  1.713 ? 0.006  ns/op
+TypeKindFrom.fromClassDesc                 S  avgt    9  1.714 ? 0.008  ns/op
+TypeKindFrom.fromClassDesc                 I  avgt    9  1.714 ? 0.005  ns/op
+TypeKindFrom.fromClassDesc                 F  avgt    9  1.713 ? 0.005  ns/op
+TypeKindFrom.fromClassDesc                 J  avgt    9  1.712 ? 0.004  ns/op
+TypeKindFrom.fromClassDesc                 D  avgt    9  1.713 ? 0.004  ns/op
+TypeKindFrom.fromClassDesc                 V  avgt    9  1.712 ? 0.008  ns/op
+TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  1.711 ? 0.005  ns/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| TypeKindFrom.fromClass | B | 1.563 | 0.646 | 141.95% |
| TypeKindFrom.fromClass | C | 1.716 | 0.786 | 118.32% |
| TypeKindFrom.fromClass | Z | 1.252 | 0.588 | 112.93% |
| TypeKindFrom.fromClass | S | 1.410 | 1.245 | 13.25% |
| TypeKindFrom.fromClass | I | 1.268 | 0.934 | 35.76% |
| TypeKindFrom.fromClass | F | 1.874 | 1.402 | 33.67% |
| TypeKindFrom.fromClass | J | 1.096 | 1.091 | 0.46% |
| TypeKindFrom.fromClass | D | 2.184 | 1.713 | 27.50% |
| TypeKindFrom.fromClass | V | 2.183 | 1.714 | 27.36% |
| TypeKindFrom.fromClass | java.lang.Object | 0.677 | 1.713 | -60.48% |
| TypeKindFrom.fromClassDesc | B | 1.010 | 1.735 | -41.79% |
| TypeKindFrom.fromClassDesc | C | 1.081 | 1.712 | -36.86% |
| TypeKindFrom.fromClassDesc | Z | 1.082 | 1.713 | -36.84% |
| TypeKindFrom.fromClassDesc | S | 1.010 | 1.714 | -41.07% |
| TypeKindFrom.fromClassDesc | I | 1.010 | 1.714 | -41.07% |
| TypeKindFrom.fromClassDesc | F | 1.010 | 1.713 | -41.04% |
| TypeKindFrom.fromClassDesc | J | 1.049 | 1.712 | -38.73% |
| TypeKindFrom.fromClassDesc | D | 1.012 | 1.713 | -40.92% |
| TypeKindFrom.fromClassDesc | V | 1.010 | 1.712 | -41.00% |
| TypeKindFrom.fromClassDesc | java.lang.Object | 1.011 | 1.711 | -40.91% |

After further improvements, the performance is significantly improved when the `TieredStopAtLevel=1` option is used. 

Without the option, 
1. the performance of from(ClassDesc) is significantly improved, 
2. and the performance of from(Class) is mostly significantly improved. 
3. The performance of from(Short.class) and from(Object) will regress.

Below are the performance numbers running on a MacBook M1.

## 1. TieredStopAtLevel=1

### 1.1 Script

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

# baseline
git checkout 2b5fce63d3789472db1d17a09ad68b074553c240
make test TEST="micro:java.lang.classfile.TypeKindFrom" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout 91d247afa409d596a53bce6dc7a04b22891d7acb
make test TEST="micro:java.lang.classfile.TypeKindFrom" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"


### 1.2 Performance Numbers


-# baseline
-Benchmark                         (typeName)  Mode  Cnt    Score    Error  Units
-TypeKindFrom.fromClass                     B  avgt    9  443.536 ? 12.381  ns/op
-TypeKindFrom.fromClass                     C  avgt    9  439.212 ?  2.298  ns/op
-TypeKindFrom.fromClass                     Z  avgt    9  432.323 ?  1.742  ns/op
-TypeKindFrom.fromClass                     S  avgt    9  435.907 ?  2.671  ns/op
-TypeKindFrom.fromClass                     I  avgt    9  429.435 ?  4.049  ns/op
-TypeKindFrom.fromClass                     F  avgt    9  445.902 ?  2.401  ns/op
-TypeKindFrom.fromClass                     J  avgt    9  429.381 ?  0.952  ns/op
-TypeKindFrom.fromClass                     D  avgt    9  451.880 ?  1.594  ns/op
-TypeKindFrom.fromClass                     V  avgt    9  452.816 ?  1.298  ns/op
-TypeKindFrom.fromClass      java.lang.Object  avgt    9  148.893 ?  0.680  ns/op
-TypeKindFrom.fromClassDesc                 B  avgt    9  164.456 ?  1.403  ns/op
-TypeKindFrom.fromClassDesc                 C  avgt    9  164.197 ?  0.567  ns/op
-TypeKindFrom.fromClassDesc                 Z  avgt    9  165.000 ?  2.452  ns/op
-TypeKindFrom.fromClassDesc                 S  avgt    9  164.275 ?  1.061  ns/op
-TypeKindFrom.fromClassDesc                 I  avgt    9  164.437 ?  1.635  ns/op
-TypeKindFrom.fromClassDesc                 F  avgt    9  164.765 ?  0.852  ns/op
-TypeKindFrom.fromClassDesc                 J  avgt    9  164.663 ?  0.529  ns/op
-TypeKindFrom.fromClassDesc                 D  avgt    9  164.284 ?  0.747  ns/op
-TypeKindFrom.fromClassDesc                 V  avgt    9  165.224 ?  1.460  ns/op
-TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  164.755 ?  1.823  ns/op

+# current
+Benchmark                         (typeName)  Mode  Cnt    Score   Error  Units
+TypeKindFrom.fromClass                     B  avgt    9  157.207 ? 4.456  ns/op
+TypeKindFrom.fromClass                     C  avgt    9  164.131 ? 0.311  ns/op
+TypeKindFrom.fromClass                     Z  avgt    9  146.979 ? 2.045  ns/op
+TypeKindFrom.fromClass                     S  avgt    9  166.140 ? 1.595  ns/op
+TypeKindFrom.fromClass                     I  avgt    9  149.969 ? 0.844  ns/op
+TypeKindFrom.fromClass                     F  avgt    9  159.677 ? 0.711  ns/op
+TypeKindFrom.fromClass                     J  avgt    9  152.904 ? 0.558  ns/op
+TypeKindFrom.fromClass                     D  avgt    9  145.127 ? 0.780  ns/op
+TypeKindFrom.fromClass                     V  avgt    9  145.311 ? 0.812  ns/op
+TypeKindFrom.fromClass      java.lang.Object  avgt    9  139.149 ? 0.519  ns/op
+TypeKindFrom.fromClassDesc                 B  avgt    9   76.149 ? 0.350  ns/op
+TypeKindFrom.fromClassDesc                 C  avgt    9   75.970 ? 0.173  ns/op
+TypeKindFrom.fromClassDesc                 Z  avgt    9   76.035 ? 0.438  ns/op
+TypeKindFrom.fromClassDesc                 S  avgt    9   76.538 ? 1.112  ns/op
+TypeKindFrom.fromClassDesc                 I  avgt    9   76.124 ? 0.308  ns/op
+TypeKindFrom.fromClassDesc                 F  avgt    9   76.083 ? 0.145  ns/op
+TypeKindFrom.fromClassDesc                 J  avgt    9   76.289 ? 0.377  ns/op
+TypeKindFrom.fromClassDesc                 D  avgt    9   76.099 ? 0.086  ns/op
+TypeKindFrom.fromClassDesc                 V  avgt    9   76.096 ? 0.130  ns/op
+TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9   75.374 ? 1.990  ns/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| TypeKindFrom.fromClass | B | 443.536 | 157.207 | 182.14% |
| TypeKindFrom.fromClass | C | 439.212 | 164.131 | 167.60% |
| TypeKindFrom.fromClass | Z | 432.323 | 146.979 | 194.14% |
| TypeKindFrom.fromClass | S | 435.907 | 166.140 | 162.37% |
| TypeKindFrom.fromClass | I | 429.435 | 149.969 | 186.35% |
| TypeKindFrom.fromClass | F | 445.902 | 159.677 | 179.25% |
| TypeKindFrom.fromClass | J | 429.381 | 152.904 | 180.82% |
| TypeKindFrom.fromClass | D | 451.880 | 145.127 | 211.37% |
| TypeKindFrom.fromClass | V | 452.816 | 145.311 | 211.62% |
| TypeKindFrom.fromClass | java.lang.Object | 148.893 | 139.149 | 7.00% |
| TypeKindFrom.fromClassDesc | B | 164.456 | 76.149 | 115.97% |
| TypeKindFrom.fromClassDesc | C | 164.197 | 75.970 | 116.13% |
| TypeKindFrom.fromClassDesc | Z | 165.000 | 76.035 | 117.01% |
| TypeKindFrom.fromClassDesc | S | 164.275 | 76.538 | 114.63% |
| TypeKindFrom.fromClassDesc | I | 164.437 | 76.124 | 116.01% |
| TypeKindFrom.fromClassDesc | F | 164.765 | 76.083 | 116.56% |
| TypeKindFrom.fromClassDesc | J | 164.663 | 76.289 | 115.84% |
| TypeKindFrom.fromClassDesc | D | 164.284 | 76.099 | 115.88% |
| TypeKindFrom.fromClassDesc | V | 165.224 | 76.096 | 117.13% |
| TypeKindFrom.fromClassDesc | java.lang.Object | 164.755 | 75.374 | 118.58% |


## 2. Non-JVM Options

### 2.1 Script

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

# baseline
git checkout 2b5fce63d3789472db1d17a09ad68b074553c240
make test TEST="micro:java.lang.classfile.TypeKindFrom"

# current
git checkout 91d247afa409d596a53bce6dc7a04b22891d7acb
make test TEST="micro:java.lang.classfile.TypeKindFrom"


## 2.2 Performance Numbers

-# baseline
-Benchmark                         (typeName)  Mode  Cnt  Score   Error  Units
-TypeKindFrom.fromClass                     B  avgt    9  1.562 ? 0.006  ns/op
-TypeKindFrom.fromClass                     C  avgt    9  1.720 ? 0.010  ns/op
-TypeKindFrom.fromClass                     Z  avgt    9  1.253 ? 0.007  ns/op
-TypeKindFrom.fromClass                     S  avgt    9  1.418 ? 0.018  ns/op
-TypeKindFrom.fromClass                     I  avgt    9  1.089 ? 0.007  ns/op
-TypeKindFrom.fromClass                     F  avgt    9  1.871 ? 0.011  ns/op
-TypeKindFrom.fromClass                     J  avgt    9  1.098 ? 0.004  ns/op
-TypeKindFrom.fromClass                     D  avgt    9  2.184 ? 0.014  ns/op
-TypeKindFrom.fromClass                     V  avgt    9  2.183 ? 0.015  ns/op
-TypeKindFrom.fromClass      java.lang.Object  avgt    9  0.660 ? 0.037  ns/op
-TypeKindFrom.fromClassDesc                 B  avgt    9  1.027 ? 0.036  ns/op
-TypeKindFrom.fromClassDesc                 C  avgt    9  1.014 ? 0.011  ns/op
-TypeKindFrom.fromClassDesc                 Z  avgt    9  1.012 ? 0.010  ns/op
-TypeKindFrom.fromClassDesc                 S  avgt    9  1.013 ? 0.008  ns/op
-TypeKindFrom.fromClassDesc                 I  avgt    9  1.018 ? 0.016  ns/op
-TypeKindFrom.fromClassDesc                 F  avgt    9  1.021 ? 0.015  ns/op
-TypeKindFrom.fromClassDesc                 J  avgt    9  1.014 ? 0.014  ns/op
-TypeKindFrom.fromClassDesc                 D  avgt    9  1.015 ? 0.016  ns/op
-TypeKindFrom.fromClassDesc                 V  avgt    9  1.027 ? 0.037  ns/op
-TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  1.015 ? 0.015  ns/op

+# current
+Benchmark                         (typeName)  Mode  Cnt  Score   Error  Units
+TypeKindFrom.fromClass                     B  avgt    9  1.091 ? 0.003  ns/op
+TypeKindFrom.fromClass                     C  avgt    9  1.559 ? 0.006  ns/op
+TypeKindFrom.fromClass                     Z  avgt    9  0.720 ? 0.080  ns/op
+TypeKindFrom.fromClass                     S  avgt    9  1.558 ? 0.005  ns/op
+TypeKindFrom.fromClass                     I  avgt    9  0.805 ? 0.027  ns/op
+TypeKindFrom.fromClass                     F  avgt    9  1.247 ? 0.005  ns/op
+TypeKindFrom.fromClass                     J  avgt    9  0.934 ? 0.002  ns/op
+TypeKindFrom.fromClass                     D  avgt    9  0.729 ? 0.075  ns/op
+TypeKindFrom.fromClass                     V  avgt    9  0.754 ? 0.003  ns/op
+TypeKindFrom.fromClass      java.lang.Object  avgt    9  0.758 ? 0.007  ns/op
+TypeKindFrom.fromClassDesc                 B  avgt    9  0.665 ? 0.037  ns/op
+TypeKindFrom.fromClassDesc                 C  avgt    9  0.695 ? 0.092  ns/op
+TypeKindFrom.fromClassDesc                 Z  avgt    9  0.662 ? 0.018  ns/op
+TypeKindFrom.fromClassDesc                 S  avgt    9  0.733 ? 0.004  ns/op
+TypeKindFrom.fromClassDesc                 I  avgt    9  0.662 ? 0.018  ns/op
+TypeKindFrom.fromClassDesc                 F  avgt    9  0.708 ? 0.066  ns/op
+TypeKindFrom.fromClassDesc                 J  avgt    9  0.659 ? 0.008  ns/op
+TypeKindFrom.fromClassDesc                 D  avgt    9  0.743 ? 0.029  ns/op
+TypeKindFrom.fromClassDesc                 V  avgt    9  0.720 ? 0.080  ns/op
+TypeKindFrom.fromClassDesc  java.lang.Object  avgt    9  0.694 ? 0.093  ns/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| TypeKindFrom.fromClass | B | 1.562 | 1.091 | 43.17% |
| TypeKindFrom.fromClass | C | 1.720 | 1.559 | 10.33% |
| TypeKindFrom.fromClass | Z | 1.253 | 0.720 | 74.03% |
| TypeKindFrom.fromClass | S | 1.418 | 1.558 | -8.99% |
| TypeKindFrom.fromClass | I | 1.089 | 0.805 | 35.28% |
| TypeKindFrom.fromClass | F | 1.871 | 1.247 | 50.04% |
| TypeKindFrom.fromClass | J | 1.098 | 0.934 | 17.56% |
| TypeKindFrom.fromClass | D | 2.184 | 0.729 | 199.59% |
| TypeKindFrom.fromClass | V | 2.183 | 0.754 | 189.52% |
| TypeKindFrom.fromClass | java.lang.Object | 0.660 | 0.758 | -12.93% |
| TypeKindFrom.fromClassDesc | B | 1.027 | 0.665 | 54.44% |
| TypeKindFrom.fromClassDesc | C | 1.014 | 0.695 | 45.90% |
| TypeKindFrom.fromClassDesc | Z | 1.012 | 0.662 | 52.87% |
| TypeKindFrom.fromClassDesc | S | 1.013 | 0.733 | 38.20% |
| TypeKindFrom.fromClassDesc | I | 1.018 | 0.662 | 53.78% |
| TypeKindFrom.fromClassDesc | F | 1.021 | 0.708 | 44.21% |
| TypeKindFrom.fromClassDesc | J | 1.014 | 0.659 | 53.87% |
| TypeKindFrom.fromClassDesc | D | 1.015 | 0.743 | 36.61% |
| TypeKindFrom.fromClassDesc | V | 1.027 | 0.720 | 42.64% |
| TypeKindFrom.fromClassDesc | java.lang.Object | 1.015 | 0.694 | 46.25% |

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

PR Comment: https://git.openjdk.org/jdk/pull/20762#issuecomment-2322212655
PR Comment: https://git.openjdk.org/jdk/pull/20762#issuecomment-2323316074

From redestad at openjdk.org  Sun Sep  1 23:34:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 1 Sep 2024 23:34:57 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
In-Reply-To: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
Message-ID: <kyBfG5OxmGA7CV8AzJwOPKU3VqibUxMmRC2uBYKnJDQ=.1b69c6f2-1632-48ef-ba53-9478d7ee9d05@github.com>

On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.
> 
> The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.
> 
> * baseline
> 
> @ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
>   @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>   @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
>   @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large
> 
> 
> * current
> 
> @ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large

This PR has public API changes that would need a CSR. Perhaps avoidable if the `OfField` override is kept.

With the benefit on `ClassDesc` being a bit dubious I'm not sure how worthwhile this one is?

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

PR Comment: https://git.openjdk.org/jdk/pull/20762#issuecomment-2322948550

From duke at openjdk.org  Sun Sep  1 23:34:57 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 1 Sep 2024 23:34:57 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
In-Reply-To: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
Message-ID: <2DsetIwWrt0xKdk0WYGoRSLmPLL0HQAMODp7j9LdnjI=.b1300d6c-4450-4236-9186-aa6e5050722f@github.com>

On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.
> 
> The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.
> 
> * baseline
> 
> @ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
>   @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>   @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
>   @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large
> 
> 
> * current
> 
> @ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large

src/java.base/share/classes/java/lang/classfile/TypeKind.java line 35:

> 33: import jdk.internal.vm.annotation.Stable;
> 34: 
> 35: import static java.lang.constant.ConstantDescs.*;

Maybe?import the?primitive?class?descriptors from?`PrimitiveClassDescImpl` in?order?to?avoid unnecessary?initialisation of?unrelated `ConstantDesc`s:
Suggestion:

import static jdk.internal.constant.PrimitiveClassDescImpl.*;

src/java.base/share/classes/java/lang/classfile/TypeKind.java line 176:

> 174:         if (cl == double.class ) return DoubleType;
> 175:         if (cl == void.class   ) return VoidType;
> 176:         else                     return ReferenceType;

This?can?call `Class?::isPrimitive()` to?perform an?implicit null?check and?short?circuit for?reference?types:
Suggestion:

        if (cl.isPrimitive()) { // implicit null check
            if (cl == boolean.class) return BooleanType;
            if (cl == byte.class   ) return ByteType;
            if (cl == char.class   ) return CharType;
            if (cl == int.class    ) return IntType;
            if (cl == long.class   ) return LongType;
            if (cl == short.class  ) return ShortType;
            if (cl == float.class  ) return FloatType;
            if (cl == double.class ) return DoubleType;
            if (cl == void.class   ) return VoidType;
        }
        return ReferenceType;

src/java.base/share/classes/java/lang/classfile/TypeKind.java line 258:

> 256:         if (desc == CD_double ) return DOUBLE;
> 257:         if (desc == CD_void   ) return VOID;
> 258:         else                    return REFERENCE;

This?can short?circuit when?`desc` is?not a?`PrimitiveClassDescImpl`:
Suggestion:

        if (desc instanceof PrimitiveClassDescImpl) {
            if (desc == CD_boolean) return BOOLEAN;
            if (desc == CD_byte   ) return BYTE;
            if (desc == CD_char   ) return CHAR;
            if (desc == CD_int    ) return INT;
            if (desc == CD_long   ) return LONG;
            if (desc == CD_short  ) return SHORT;
            if (desc == CD_float  ) return FLOAT;
            if (desc == CD_double ) return DOUBLE;
            if (desc == CD_void   ) return VOID;
        }
        return REFERENCE;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20762#discussion_r1739629316
PR Review Comment: https://git.openjdk.org/jdk/pull/20762#discussion_r1737538239
PR Review Comment: https://git.openjdk.org/jdk/pull/20762#discussion_r1739630850

From swen at openjdk.org  Sun Sep  1 23:34:57 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 1 Sep 2024 23:34:57 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
In-Reply-To: <2DsetIwWrt0xKdk0WYGoRSLmPLL0HQAMODp7j9LdnjI=.b1300d6c-4450-4236-9186-aa6e5050722f@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
 <2DsetIwWrt0xKdk0WYGoRSLmPLL0HQAMODp7j9LdnjI=.b1300d6c-4450-4236-9186-aa6e5050722f@github.com>
Message-ID: <EyMF0qMBKgndqjKaZVFiEHf__NgvPfVOJTDBBXFmGq8=.32f95819-1e41-4f7c-929d-2390c612bec3@github.com>

On Fri, 30 Aug 2024 00:19:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.
>> 
>> The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.
>> 
>> * baseline
>> 
>> @ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
>>   @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>>   @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
>>   @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large
>> 
>> 
>> * current
>> 
>> @ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large
>
> src/java.base/share/classes/java/lang/classfile/TypeKind.java line 176:
> 
>> 174:         if (cl == double.class ) return DoubleType;
>> 175:         if (cl == void.class   ) return VoidType;
>> 176:         else                     return ReferenceType;
> 
> This?can?call `Class?::isPrimitive()` to?perform an?implicit null?check and?short?circuit for?reference?types:
> Suggestion:
> 
>         if (cl.isPrimitive()) { // implicit null check
>             if (cl == boolean.class) return BooleanType;
>             if (cl == byte.class   ) return ByteType;
>             if (cl == char.class   ) return CharType;
>             if (cl == int.class    ) return IntType;
>             if (cl == long.class   ) return LongType;
>             if (cl == short.class  ) return ShortType;
>             if (cl == float.class  ) return FloatType;
>             if (cl == double.class ) return DoubleType;
>             if (cl == void.class   ) return VoidType;
>         }
>         return ReferenceType;

https://github.com/openjdk/jdk/pull/20759#issuecomment-2317655533 
Refer to @cl4es 's comment, isPrimitive is a native method and will be slow

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20762#discussion_r1737599447

From redestad at openjdk.org  Sun Sep  1 23:34:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 1 Sep 2024 23:34:57 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
In-Reply-To: <EyMF0qMBKgndqjKaZVFiEHf__NgvPfVOJTDBBXFmGq8=.32f95819-1e41-4f7c-929d-2390c612bec3@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
 <2DsetIwWrt0xKdk0WYGoRSLmPLL0HQAMODp7j9LdnjI=.b1300d6c-4450-4236-9186-aa6e5050722f@github.com>
 <EyMF0qMBKgndqjKaZVFiEHf__NgvPfVOJTDBBXFmGq8=.32f95819-1e41-4f7c-929d-2390c612bec3@github.com>
Message-ID: <K-xEMJg9Gm5K-s08xnHCkbWwYEYS3N22YMPeBD8Drgs=.3ad7c696-6ba2-4a77-9acc-1bfe5eecb10d@github.com>

On Fri, 30 Aug 2024 01:21:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/TypeKind.java line 176:
>> 
>>> 174:         if (cl == double.class ) return DoubleType;
>>> 175:         if (cl == void.class   ) return VoidType;
>>> 176:         else                     return ReferenceType;
>> 
>> This?can?call `Class?::isPrimitive()` to?perform an?implicit null?check and?short?circuit for?reference?types:
>> Suggestion:
>> 
>>         if (cl.isPrimitive()) { // implicit null check
>>             if (cl == boolean.class) return BooleanType;
>>             if (cl == byte.class   ) return ByteType;
>>             if (cl == char.class   ) return CharType;
>>             if (cl == int.class    ) return IntType;
>>             if (cl == long.class   ) return LongType;
>>             if (cl == short.class  ) return ShortType;
>>             if (cl == float.class  ) return FloatType;
>>             if (cl == double.class ) return DoubleType;
>>             if (cl == void.class   ) return VoidType;
>>         }
>>         return ReferenceType;
>
> https://github.com/openjdk/jdk/pull/20759#issuecomment-2317655533 
> Refer to @cl4es 's comment, isPrimitive is a native method and will be slow

I said it can be relatively slow in the interpreter. This was an invitation to measure carefully (with and without `-Xint`), not an authoritative statement that we should avoid `Class::isPrimitive` everywhere. I think you need to provide supporting evidence that these kinds of optimizations are worthwhile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20762#discussion_r1738583597

From dholmes at openjdk.org  Mon Sep  2 03:54:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Sep 2024 03:54:24 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <SYJj6vBnDnUNNJAXuWwWW1m_91b_eyMDf0oJp2aliYg=.1966ffb7-837b-447d-9c74-73e99d89a6e1@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
 <SYJj6vBnDnUNNJAXuWwWW1m_91b_eyMDf0oJp2aliYg=.1966ffb7-837b-447d-9c74-73e99d89a6e1@github.com>
Message-ID: <Zyp87MpIrDS4SH7xVVS_AaHeeNe0wfA7u7A_CvWn6nI=.b9a338d0-2b09-444d-b897-e4e4a3201b42@github.com>

On Fri, 30 Aug 2024 20:45:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exclude test on 32-bit
>
> Overall it looks good to me, although I don't have experience adding a new JNI API (the dtrace probes were new to me), but it seems you are following what is already in place for other functions, and the testing looks good.

Thanks for the review @plummercj !

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

PR Comment: https://git.openjdk.org/jdk/pull/20784#issuecomment-2323760808

From dholmes at openjdk.org  Mon Sep  2 04:12:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Sep 2024 04:12:26 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <sl8l59-K_dTtCIlRlfwnD09JBWLYUiivU2V6hN-TSz0=.5c7e95af-4484-4a5f-8f14-f3b2e6cb5da0@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <sl8l59-K_dTtCIlRlfwnD09JBWLYUiivU2V6hN-TSz0=.5c7e95af-4484-4a5f-8f14-f3b2e6cb5da0@github.com>
Message-ID: <vFrL6wW1otFJIqxJxGMxlHO4qVEyxmV8mewgYMqZOcY=.e618476f-9dd5-402d-aad1-b573fe24e9d4@github.com>

On Sun, 1 Sep 2024 16:30:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> This does make me wonder: What if the new method for checking if the VM was statically linked was inlined? Then the problem comes back yet again as the object files need to be recompiled once more. This is possible if Link Time Optimization is switched on, and I don't like the implication that LTO might be removed as a result just to make this work

Wouldn't such link-time "inlining" only appear in the object code stored within the library, not in the original object file?

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

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2323775705

From jwaters at openjdk.org  Mon Sep  2 04:15:21 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 2 Sep 2024 04:15:21 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <vFrL6wW1otFJIqxJxGMxlHO4qVEyxmV8mewgYMqZOcY=.e618476f-9dd5-402d-aad1-b573fe24e9d4@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <sl8l59-K_dTtCIlRlfwnD09JBWLYUiivU2V6hN-TSz0=.5c7e95af-4484-4a5f-8f14-f3b2e6cb5da0@github.com>
 <vFrL6wW1otFJIqxJxGMxlHO4qVEyxmV8mewgYMqZOcY=.e618476f-9dd5-402d-aad1-b573fe24e9d4@github.com>
Message-ID: <I53OCnlTDqFzoRZcF1xpErSfVb7VstP8BP4vXi8YdTs=.fa34dc14-dcfc-403c-904f-acb782f2a553@github.com>

On Mon, 2 Sep 2024 04:09:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > This does make me wonder: What if the new method for checking if the VM was statically linked was inlined? Then the problem comes back yet again as the object files need to be recompiled once more. This is possible if Link Time Optimization is switched on, and I don't like the implication that LTO might be removed as a result just to make this work
> 
> Wouldn't such link-time "inlining" only appear in the object code stored within the library, not in the original object file?

Ah, you're right, good catch. I got mixed up with the implementation details of different compilers there, sorry

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

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2323778397

From viktor.klang at oracle.com  Mon Sep  2 08:36:54 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 2 Sep 2024 08:36:54 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
Message-ID: <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Anthony,

Thank you for your patience, I needed some time to experiment and think about your feedback.

>* how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?

If looking at the past to inform extrapolation into the future, then the trend is going in the direction of improving over time.

>Gatherers.identity()

I still need some time to experiment with this, as there are some implications.

For instance, if you do: Steam.of(1).gather(Gatherers.identity()) you'd want that gatherer to be dropped since it is a no-op, but you can't really do that without breaking the contract of Stream.gather, as that operation should "consume" the original Stream reference and return a new one (to preserve stream building linearity), so you'd still need to create a new ReferencePipeline instance which is a copy of the current one, and mark the previous as consumed)?in essence Stream.gather(identity) wouldn't be a no-op.

There are some other, performance-related, things I'll need to verify as well before coming to any conclusion on this.

>Gatherers.concat(Stream<T> stream)

Creating such a Gatherer means that it is not reusable. You'd need to have a Supplier<Stream<T>>. Otherwise this happens:

jshell>     public static <T> Gatherer<T, ?, T> concat(Stream<T> newStream) {
   ...>         return Gatherer.of(
   ...>                 Gatherer.Integrator.ofGreedy((_, e, d) -> d.push(e)),
   ...>                 (_, d) -> newStream.sequential().allMatch(d::push)
   ...>         );
   ...>     }
   ...>
|  created method concat(Stream<T>)

jshell> var inject = concat(Stream.of(1,2))
inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000db898 at 1068e947]

jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
|  Exception java.lang.IllegalStateException: stream has already been operated upon or closed
|        at AbstractPipeline.evaluate (AbstractPipeline.java:260)
|        at ReferencePipeline.allMatch (ReferencePipeline.java:677)
|        at lambda$concat$1 (#4:4)
|        at Gatherers$Composite.lambda$impl$3 (Gatherers.java:611)
|        at GathererOp$GatherSink.end (GathererOp.java:181)
|        at AbstractPipeline.copyInto (AbstractPipeline.java:571)
|        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
|        at AbstractPipeline.evaluate (AbstractPipeline.java:636)
|        at AbstractPipeline.evaluateToArrayNode (AbstractPipeline.java:291)
|        at ReferencePipeline.toArray (ReferencePipeline.java:656)
|        at ReferencePipeline.toArray (ReferencePipeline.java:662)
|        at ReferencePipeline.toList (ReferencePipeline.java:667)
|        at (#6:1)

That being said, given how little code it takes to implement something like that, I am not sure it warrants inclusion:

jshell>     public static <T> Gatherer<T, ?, T> concat(Supplier<? extends Stream<T>> newStream) {
   ...>         return Gatherer.of(
   ...>                 Gatherer.Integrator.ofGreedy((_, e, d) -> d.push(e)),
   ...>                 (_, d) -> newStream.get().sequential().allMatch(d::push)
   ...>         );
   ...>     }
|  created method concat(Supplier<? extends Stream<T>>)

jshell> var inject = concat(() -> Stream.of(1,2))
inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000d9c70 at 1a052a00]

jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
$1 ==> [0, 1, 2, 1, 2]

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Anthony Vanelverdinghe <dev at anthonyv.be>
Sent: Monday, 19 August 2024 20:37
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Stream Gatherers (JEP 473) feedback

August 15, 2024 at 1:27 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> Hi Anthony,

Hi Viktor

> Thanks for the input?it's much appreciated!
>
> Introducing yet another, user-facing, type parameter to get slightly improved type inference is unfortunately for me a too high of a price to pay. Ideally, type inference/unification will be improved over time making this issue go away without impacting any signatures.

My arguments would be:
* the type parameter enables using subtypes of Downstream, e.g. `Gatherer::integrator` could return an `Integrator<A, T, R, SpecialDownstream<R>>`
* the type parameter improves type inference
* the type parameter would increase usability. In my experience, nearly all Gatherers are created through the factory methods in Gatherer. And thanks to the improved type inference, I assert that all factory method invocations would work without any type arguments at all. Nowadays type inference is so good that I found it remarkable how often (relatively speaking) I need to provide type arguments with Gatherers, compared to other generic APIs. A substantial amount of Java developers has probably never even had to provide type arguments before, so being able to eliminate their need from the Gatherers API as well seems like a considerable advantage to me
* how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?

> I'm warming up to the idea of shipping a Gatherers.identity(), and before that happens I would like to see more use-cases where having such a thing would provide a real edge. I can come up with a bunch of synthetic scenarios where it's a win, but it's always better to see app logic numbers.

To summarize previous mails, my arguments are:
* it's a common Gatherer. Gatherers of the form `Gatherer<T, ?, T>` will likely have a degenerate case that is the identity. Some actual factory methods are `append(T... elements)` and `concat(Stream<T> stream)`, `prepend(T... elements)`, and `withInterpolationAt(Set<Instant> instants)`.
* optimization: if a Stream pipeline only contains compositions of `Gatherer.identity()`, the Gatherers can be eliminated entirely from the pipeline and characteristics can be propagated. So for example `list.stream().gather(withInterpolationAt(aSetThatHappensToBeEmpty)).count()` would be optimized to `list.stream().count()` and return instantly. Note that while a homemade implementation could optimize its `andThen` implementation, it wouldn't be able to optimize `Gatherer::andThen` and `Stream::gather`.
* API consistency: there's `Function.identity()`, so why not `Gatherers.identity()` (or `Gatherer.identity()`)? Actually I'd argue this method is more useful for Gatherers, since for Functions, this is often written as `o -> o` instead. For Gatherers there's no alternative like that.

On a final note, in case it hasn't been done yet, I'd like to propose `Gatherers.concat(Stream<T> stream)`. The current `Stream::concat` doesn't allow fluent/readable concatenation of multiple streams.

> Getting rid of the rawtypes in Value could be done, at any point since it isn't exposed to user code. I'll keep this in mind for any upcoming maintenance ?
>
> Keep the feedback coming ?
>
> Cheers,
>
> ?

Kind regards,
Anthony

> **Viktor Klang**
> Software Architect, Java Platform Group
>
> Oracle
>
> ????????????????????????????????????????????????????????????????
>
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Tuesday, 13 August 2024 18:32
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
>
> Hi Viktor
>
> Your previous response inspired me to experiment some more with Gatherers
>
> As a result I'd like to make a couple propositions:
>
> * add an additional type parameter.
>
>   After doing so, type inference no longer needs any assistance:
>
>   `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
>
> * add an identity Gatherer with an optimized `andThen` implementation
>
>   as well as an optimization in the default implementation of `Gatherer::andThen`
>
> * eliminate the use of raw types in `Gatherers.Value`
>
> Code that implements these propositions is in this gist: https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVct8oxUqg$
>
> Kind regards,
>
> Anthony
>
> July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > Hi Anthony,
>
> >
>
> > >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
>
> >
>
> > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
>
> >
>
> > Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
>
> >
>
> > >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
>
> >
>
> > Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
>
> >
>
> > >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
>
> >
>
> > Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVdv0LXetA$
>
> >
>
> > Cheers,
>
> >
>
> > ?
>
> >
>
> > **Viktor Klang**
>
> > Software Architect, Java Platform Group
>
> >
>
> > Oracle
>
> >
>
> > ????????????????????????????????????????????????????????????????
>
> >
>
> > **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
>
> > **Sent:** Tuesday, 30 July 2024 17:20
>
> > **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> > **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
> >
>
> >
>
> > July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >

>
> > >
>
> >
>
> > > Hi Anthony,
>
> >
>
> > Hi Viktor
>
> >
>
> > > Thank you for your patience, and for providing feedback, it is always much appreciated.
>
> >
>
> > >
>
> >
>
> > > >When writing factory methods for Gatherers, there's sometimes a
>
> >
>
> > > degenerate case that requires returning a no-op Gatherer. So I'd like a
>
> >
>
> > > way to mark a no-op Gatherer as such, allowing the Stream implementation
>
> >
>
> > > to recognize and eliminate it from the pipeline. One idea is to add
>
> >
>
> > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
>
> >
>
> > > Another is to add Gatherers.identity(), analogous to Function.identity().
>
> >
>
> > >
>
> >
>
> > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
>
> >
>
> > > but rather adding it in case it was deemed necessary.
>
> >
>
> > >
>
> >
>
> > > Do you have a concrete use-case (code) that you could share?
>
> >
>
> > The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
>
> >
>
> > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
>
> >
>
> > > >Sometimes a factory method returns a Gatherer that only works correctly
>
> >
>
> > > if the upstream has certain characteristics, for example
>
> >
>
> > > Spliterator.SORTED or Spliterator.DISTINCT.
>
> >
>
> > >
>
> >
>
> > > Do you have a concrete use-case (code) that you could share?
>
> >
>
> > All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
>
> >
>
> > > >One idea is to add methods
>
> >
>
> > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
>
> >
>
> > > implementation would be able to recognize and eliminate these from the
>
> >
>
> > > pipeline if the upstream already has these characteristics. That way
>
> >
>
> > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
>
> >
>
> > > idea is to provide a Gatherer with a way to inspect the upstream
>
> >
>
> > > characteristics. If the upstream is missing the required
>
> >
>
> > > characteristic(s), it could then throw an IllegalStateException.
>
> >
>
> > I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
>
> >
>
> > > For a rather long time Gatherer had characteristics, however,
>
> >
>
> > > what I noticed is that given composition of Gatherers what ended up happening
>
> >
>
> > > almost always was that the combination of characteristics added overhead and devolved into the empty set
>
> >
>
> > > real fast.
>
> >
>
> > >
>
> >
>
> > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
>
> >
>
> > > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
>
> >
>
> > In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
>
> >
>
> > That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
>
> >
>
> > > >The returns clause of Gatherer.Integrator::integrate just states "true
>
> >
>
> > > if subsequent integration is desired, false if not". In particular, it
>
> >
>
> > > doesn't document the behavior I'm observing, that returning false also
>
> >
>
> > > causes downstream to reject any further output elements.
>
> >
>
> > >
>
> >
>
> > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
>
> >
>
> > I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$  ), but this is indeed already fixed in JDK 23-ea.
>
> >
>
> > This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
>
> >
>
> > > Cheers,
>
> >
>
> > >
>
> >
>
> > > ?
>
> >
>
> > >
>
> >
>
> > > **Viktor Klang**
>
> >
>
> > > Software Architect, Java Platform Group
>
> >
>
> > >
>
> >
>
> > > Oracle
>
> >
>
> > Kind regards,
>
> >
>
> > Anthony
>
> >
>
> > > ????????????????????????????????????????????????????????????????
>
> >
>
> > >
>
> >
>
> > > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
>
> >
>
> > > **Sent:** Saturday, 27 July 2024 08:57
>
> >
>
> > > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> >
>
> > > **Subject:** Stream Gatherers (JEP 473) feedback
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > When writing factory methods for Gatherers, there's sometimes a
>
> >
>
> > >
>
> >
>
> > > degenerate case that requires returning a no-op Gatherer. So I'd like a
>
> >
>
> > >
>
> >
>
> > > way to mark a no-op Gatherer as such, allowing the Stream implementation
>
> >
>
> > >
>
> >
>
> > > to recognize and eliminate it from the pipeline. One idea is to add
>
> >
>
> > >
>
> >
>
> > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
>
> >
>
> > >
>
> >
>
> > > Another is to add Gatherers.identity(), analogous to Function.identity().
>
> >
>
> > >
>
> >
>
> > > Sometimes a factory method returns a Gatherer that only works correctly
>
> >
>
> > >
>
> >
>
> > > if the upstream has certain characteristics, for example
>
> >
>
> > >
>
> >
>
> > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
>
> >
>
> > >
>
> >
>
> > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
>
> >
>
> > >
>
> >
>
> > > implementation would be able to recognize and eliminate these from the
>
> >
>
> > >
>
> >
>
> > > pipeline if the upstream already has these characteristics. That way
>
> >
>
> > >
>
> >
>
> > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
>
> >
>
> > >
>
> >
>
> > > idea is to provide a Gatherer with a way to inspect the upstream
>
> >
>
> > >
>
> >
>
> > > characteristics. If the upstream is missing the required
>
> >
>
> > >
>
> >
>
> > > characteristic(s), it could then throw an IllegalStateException.
>
> >
>
> > >
>
> >
>
> > > The returns clause of Gatherer.Integrator::integrate just states "true
>
> >
>
> > >
>
> >
>
> > > if subsequent integration is desired, false if not". In particular, it
>
> >
>
> > >
>
> >
>
> > > doesn't document the behavior I'm observing, that returning false also
>
> >
>
> > >
>
> >
>
> > > causes downstream to reject any further output elements.
>
> >
>
> > >
>
> >
>
> > > In the Implementation Requirements section of Gatherer, rephrasing
>
> >
>
> > >
>
> >
>
> > > "Outputs and state later in the input sequence will be discarded if
>
> >
>
> > >
>
> >
>
> > > processing an earlier partition short-circuits." to something like the
>
> >
>
> > >
>
> >
>
> > > following would be clearer to me: "As soon as any partition
>
> >
>
> > >
>
> >
>
> > > short-circuits, the whole Gatherer short-circuits. The state of other
>
> >
>
> > >
>
> >
>
> > > partitions is discarded, i.e. there are no further invocations of the
>
> >
>
> > >
>
> >
>
> > > combiner. The finisher is invoked with the short-circuiting partition's
>
> >
>
> > >
>
> >
>
> > > state." I wouldn't mention discarding of outputs, since that's implied
>
> >
>
> > >
>
> >
>
> > > by the act of short-circuiting.
>
> >
>
> > >
>
> >
>
> > > Anthony
>
> >
>
> > >
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240902/5ad1380c/attachment-0001.htm>

From pminborg at openjdk.org  Mon Sep  2 08:56:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 2 Sep 2024 08:56:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
Message-ID: <U1JQ2NfdXUV6mhhdmxDQQsYARgQjrEYqYsbJZwnH3ls=.e7b433f6-f0cb-4833-8724-b3afc76886df@github.com>

On Fri, 30 Aug 2024 10:51:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/87e837b6-30e4-4299-a9a1-14776e575825)
>> 
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert copyright year
>  - Move logic back to AMSI

Here is the performance improvement for Linux a64. Looks like a significant improvement.

![image](https://github.com/user-attachments/assets/43d7e07b-775f-4382-8aa1-3893dfe635a6)

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

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2324186401

From pminborg at openjdk.org  Mon Sep  2 08:59:22 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 2 Sep 2024 08:59:22 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
 <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>
Message-ID: <7Bh_uU7pTTtY-bEIasYBKDLRshFPU_TTQSKlt37iFNU=.ce313a17-340d-4736-9a81-b56facf4ab7d@github.com>

On Fri, 30 Aug 2024 14:15:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 208:
>> 
>>> 206:             }
>>> 207:             final long u = Byte.toUnsignedLong(value);
>>> 208:             final long longValue = u << 56 | u << 48 | u << 40 | u << 32 | u << 24 | u << 16 | u << 8 | u;
>> 
>> this can be u * 0xFFFFFFFFFFFFL if value != 0 and just 0L if not: not sure if fast(er), need to measure.
>> 
>> Most of the time filling is happy with 0 since zeroing is the most common case
>
>> this can be u * 0xFFFFFFFFFFFFL if value != 0 and just 0L if not: not sure if fast(er), need to measure.
>> 
>> Most of the time filling is happy with 0 since zeroing is the most common case
> 
> It's a clever trick. However, I was looking at similar tricks and found that the time spent here is irrelevant (e.g. I tried to always force `0` as the value, and couldn't see any difference).

If I run:


    @Benchmark
    public long shift() {
        return ELEM_SIZE << 56 | ELEM_SIZE << 48 | ELEM_SIZE << 40 | ELEM_SIZE << 32 | ELEM_SIZE << 24 | ELEM_SIZE << 16 | ELEM_SIZE << 8 | ELEM_SIZE;
    }

    @Benchmark
    public long mul() {
        return ELEM_SIZE * 0xFFFF_FFFF_FFFFL;
    }

Then I get:

Benchmark       (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
TestFill.mul             31  avgt   30  0.586 ? 0.045  ns/op
TestFill.shift           31  avgt   30  0.938 ? 0.017  ns/op

On my M1 machine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1740564110

From alanb at openjdk.org  Mon Sep  2 09:08:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Sep 2024 09:08:18 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
Message-ID: <8Lgmm7EJJ6BLMS1hIp6eWvnUPw-pzO-Svw9I8g33JeU=.44b18408-f1a7-4119-94c4-c8f7665bac61@github.com>

On Fri, 30 Aug 2024 05:21:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of a new method added to the JNI specification.
>> 
>> From the CSR request:
>> 
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
>> 
>> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
>> 
>> Solution
>> 
>> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
>> 
>> ---
>> 
>> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
>> 
>> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
>> 
>> Testing:
>>  - new test added
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude test on 32-bit

Deprecating the existing function and introducing the new function looks okay.

The test is really 3 tests in one (GetStringUTFLength returning a truncated size, GetStringUTFLength with -Xcheck:jni prints a warning, and GetStringUTFLengthAsLong returns the long size). Personally I would have done this as 3 test cases rather in one launch with -Xcheck:jni but that's your choice.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20784#pullrequestreview-2275089037

From alanb at openjdk.org  Mon Sep  2 09:09:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Sep 2024 09:09:20 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
Message-ID: <s6R98Hq5bTpOO3X0N51spAxPMqxK8bMug9a9aA4GAsI=.599c8792-35fb-4fd3-96d1-9b16ec1cb5b4@github.com>

On Fri, 30 Aug 2024 21:39:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8003887: Free value allocated in and returned by getFinalPath()

Are you planning to add a test for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/20801#issuecomment-2324214886

From ihse at openjdk.org  Mon Sep  2 09:17:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 2 Sep 2024 09:17:28 GMT
Subject: Integrated: 8338768: Introduce runtime lookup to check for static
 builds
In-Reply-To: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
Message-ID: <7ZCNx3fBoTkmUDxGYAcN6eqygCSF-kxH3vBPSczQqaA=.85487425-1e4f-4496-92f7-92d7a6d69156@github.com>

On Wed, 21 Aug 2024 21:53:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
> 
> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
> 
> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.

This pull request has now been integrated.

Changeset: a136a85b
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5
Stats:     205 lines in 12 files changed: 109 ins; 21 del; 75 mod

8338768: Introduce runtime lookup to check for static builds

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Jiangli Zhou <jiangli at openjdk.org>
Reviewed-by: prr, jiangli, alanb

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

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

From mcimadamore at openjdk.org  Mon Sep  2 09:39:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Sep 2024 09:39:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <4rq3-ERDHkTJqXA32I-ynjWrmZRI0ABlj-oQqkbPabg=.33dec849-fb55-4285-8861-531f149ca559@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <4rq3-ERDHkTJqXA32I-ynjWrmZRI0ABlj-oQqkbPabg=.33dec849-fb55-4285-8861-531f149ca559@github.com>
Message-ID: <jm1bWvBG9seWf-eSitgGX1ZIIBQ8K1J9ndPaKa0PZ-4=.5a0dcf1b-419d-4bd8-9649-020cd40cdebb@github.com>

On Fri, 30 Aug 2024 22:04:39 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> All of these strategies are better than what we have now, probably because the existing instrinsics still perform some poor decision, but I haven't dug yet into perfasm out to see what it does wrong; maybe is something which could be fixed in the intrinsic itself?

I'm no intrinsics expert, but if I had to guess I'd say that the intrinsics we have do not specialize for small sizes. Also, the use of vector instructions typically comes with additional alignment constraints - meaning that we need a pre-loop (and sometimes a post-loop). This logic, while faster for bigger sizes, has some drawbacks for smaller sizes.

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

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2324276883

From mcimadamore at openjdk.org  Mon Sep  2 09:39:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Sep 2024 09:39:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <U1JQ2NfdXUV6mhhdmxDQQsYARgQjrEYqYsbJZwnH3ls=.e7b433f6-f0cb-4833-8724-b3afc76886df@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <U1JQ2NfdXUV6mhhdmxDQQsYARgQjrEYqYsbJZwnH3ls=.e7b433f6-f0cb-4833-8724-b3afc76886df@github.com>
Message-ID: <BRSoztZHBsmaftgGRen7zBAEF_aZ3NlBw7x42IjIr50=.217e8f69-1801-4f56-ace4-d1daa7768353@github.com>

On Mon, 2 Sep 2024 08:53:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Here is the performance improvement for Linux a64. Looks like a significant improvement.

This looks good. Again, the goal of this PR is not to squeeze every nanosecond out - but, rather, to achieve a performance model that is "sensible" - whereby, if you work on smallish segments you get more or less the same degree of performance you get when operating on small arrays. These changes seem to achieve that goal.

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

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2324280589

From mcimadamore at openjdk.org  Mon Sep  2 09:39:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Sep 2024 09:39:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <7Bh_uU7pTTtY-bEIasYBKDLRshFPU_TTQSKlt37iFNU=.ce313a17-340d-4736-9a81-b56facf4ab7d@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
 <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>
 <7Bh_uU7pTTtY-bEIasYBKDLRshFPU_TTQSKlt37iFNU=.ce313a17-340d-4736-9a81-b56facf4ab7d@github.com>
Message-ID: <AMGRZZcYd6ybuKnxYlVXcR1k5xOjHAVYXMxexG4Jvu0=.9b790868-9864-4b43-9c92-ccb03addcb39@github.com>

On Mon, 2 Sep 2024 08:56:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> this can be u * 0xFFFFFFFFFFFFL if value != 0 and just 0L if not: not sure if fast(er), need to measure.
>>> 
>>> Most of the time filling is happy with 0 since zeroing is the most common case
>> 
>> It's a clever trick. However, I was looking at similar tricks and found that the time spent here is irrelevant (e.g. I tried to always force `0` as the value, and couldn't see any difference).
>
> If I run:
> 
> 
>     @Benchmark
>     public long shift() {
>         return ELEM_SIZE << 56 | ELEM_SIZE << 48 | ELEM_SIZE << 40 | ELEM_SIZE << 32 | ELEM_SIZE << 24 | ELEM_SIZE << 16 | ELEM_SIZE << 8 | ELEM_SIZE;
>     }
> 
>     @Benchmark
>     public long mul() {
>         return ELEM_SIZE * 0xFFFF_FFFF_FFFFL;
>     }
> 
> Then I get:
> 
> Benchmark       (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
> TestFill.mul             31  avgt   30  0.586 ? 0.045  ns/op
> TestFill.shift           31  avgt   30  0.938 ? 0.017  ns/op
> 
> On my M1 machine.

I found similar small improvements to be had (I wrote about them offline) when replacing the bitwise-based tests (e.g. `foo & 4 != 0`) with a more explicit check for `remainingBytes >=4`. Seems like bitwise operations are not as optimized (or perhaps the assembly instructions for them is overall more convoluted - I haven't checked).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1740612559

From dholmes at openjdk.org  Mon Sep  2 09:50:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Sep 2024 09:50:18 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <8Lgmm7EJJ6BLMS1hIp6eWvnUPw-pzO-Svw9I8g33JeU=.44b18408-f1a7-4119-94c4-c8f7665bac61@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
 <8Lgmm7EJJ6BLMS1hIp6eWvnUPw-pzO-Svw9I8g33JeU=.44b18408-f1a7-4119-94c4-c8f7665bac61@github.com>
Message-ID: <BhvTz9h6vEcW-D9i1xmDuviwJ5o_fhWRpKqYGjZBszE=.1ae6157a-cf35-4fb7-8f6f-05ce10d086b8@github.com>

On Mon, 2 Sep 2024 09:05:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exclude test on 32-bit
>
> Deprecating the existing function and introducing the new function looks okay.
> 
> The test is really 3 tests in one (GetStringUTFLength returning a truncated size, GetStringUTFLength with -Xcheck:jni prints a warning, and GetStringUTFLengthAsLong returns the long size). Personally I would have done this as 3 test cases rather in one launch with -Xcheck:jni but that's your choice.

Thanks for the review @AlanBateman . I like the test the way it is.

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

PR Comment: https://git.openjdk.org/jdk/pull/20784#issuecomment-2324302820

From asotona at openjdk.org  Mon Sep  2 10:08:46 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 10:08:46 GMT
Subject: RFR: 8339368: Switch targets are not inflated in CodeModel if no
 StackMap
Message-ID: <H1d-KYsWJtng8JttZ8PQMVhZ1iIZ5usGVN5rKBRw6-M=.479358c9-0a3e-44aa-af7c-bb53cf2e810d@github.com>

ClassFile API use an alternate labels inflation method for class versions < 50 (where StackMapTable attribute is optional).
The alternate method missed label inflation of lookup switch and table switch instructions.
This patch fixes the label inflation method for for class versions < 50 and adds relevant test.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8339368: Switch targets are not inflated in CodeModel if no StackMap

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

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

From mbaesken at openjdk.org  Mon Sep  2 11:48:48 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Sep 2024 11:48:48 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and function
 warnings
Message-ID: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>

We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
/priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
    char exePath[PATH_MAX];
         ^
/priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
    int ret;
        ^
/priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
    char fn[32];
         ^

This seems to be related to the recent make changes
8339156: Use more fine-granular clang unused warnings
https://bugs.openjdk.org/browse/JDK-8339156
(we use clang too on AIX)

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

Commit messages:
 - JDK-8339364

Changes: https://git.openjdk.org/jdk/pull/20812/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20812&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339364
  Stats: 61 lines in 14 files changed: 9 ins; 36 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20812.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20812/head:pull/20812

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

From clanger at openjdk.org  Mon Sep  2 12:20:20 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 2 Sep 2024 12:20:20 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings
In-Reply-To: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
Message-ID: <21Qc2WxZ7rcyk2WSogCUe3L2ZMbctnz7QF7XdorWFn0=.6b90a395-9f9b-4408-a05f-abb0e5008b72@github.com>

On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>     char exePath[PATH_MAX];
>          ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>     int ret;
>         ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>     char fn[32];
>          ^
> 
> This seems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)

Looks good and seems like the warning helped to clean out coding in a few places.

src/java.desktop/unix/native/common/awt/X11Color.c line 1236:

> 1234:     for (int i = 0; i < num_colors; i++)
> 1235:         alloc_col (awt_display, awtData->awt_cmap, red (rgbColors [i]),
> 1236:                      green (rgbColors [i]), blue (rgbColors [i]), -1,

Seems like indentation here could be improved a bit.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2275486151
PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1740824222

From jbhateja at openjdk.org  Mon Sep  2 12:20:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 2 Sep 2024 12:20:59 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Review comments resolved

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/c42b4afa..767aeef3

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

  Stats: 249 lines in 9 files changed: 75 ins; 67 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From jbhateja at openjdk.org  Mon Sep  2 12:21:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 2 Sep 2024 12:21:00 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <T8PSaIWEe2ywQsBrn1BSoirmIGnIe7jBP_XSOkjWgLQ=.48b2900b-d326-47b1-a73e-f2352e73140f@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
 <T8PSaIWEe2ywQsBrn1BSoirmIGnIe7jBP_XSOkjWgLQ=.48b2900b-d326-47b1-a73e-f2352e73140f@github.com>
Message-ID: <fNMV86TdmNmcWGiulFgdENCIYSTs5lv6PCKDPSNQy2Q=.1a84e138-2db0-4f30-a393-a6101f22e62a@github.com>

On Mon, 26 Aug 2024 22:17:55 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 10229:
> 
>> 10227:   InstructionMark im(this);
>> 10228:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
>> 10229:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);
> 
> vex_w could be false here.

Encoding specification mentions W bit gets ignored, so no functional issues, will make it false to comply with our convention.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6698:
> 
>> 6696:   // Unsigned values ranges comprise of only +ve numbers, thus there exist only an upper bound saturation.
>> 6697:   // overflow = ((UMAX - MAX(SRC1 & SRC2)) <u MIN(SRC1, SRC2)) >>> 31 == 1
>> 6698:   // Res = Signed Add INP1, INP2
> 
> The >>> 31 is not coded so comment could be improved to match the code.
> Comment has SRC1/INP1 term mixed.
> Also, could overflow not be implemented based on much simpler Java scalar algo:
> Overflow = Res <u  (INP1 | INP2)
> This is much straight forward, also evex supports unsigned comparison.

Java scalar algo was empirically proved to hold good, I also verified with Alive2 solver which proved its semantic equivalence to HD section 2-13 based vector implementation.
Here is the link to Alive2 solver which operates on LLVM IR inputs.
[https://alive2.llvm.org/ce/z/XDQ7dY](https://alive2.llvm.org/ce/z/XDQ7dY)

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6749:
> 
>> 6747:   vpor(xtmp2, xtmp2, src2, vlen_enc);
>> 6748:   // Compute mask for muxing T1 with T3 using SRC1.
>> 6749:   vpsign_extend_dq(etype, xtmp4, src1, vlen_enc);
> 
> I don't think we need to do the sign extension. The blend instruction uses most significant bit to do the blend.

Original vector is has double / quad word lanes which are being blended using byte level mask, sign extension will ensure that sign bit is propagated to MSB bits of each constituent byte mask corresponding double / quad word source lane.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6939:
> 
>> 6937: 
>> 6938:   // Compose saturating min/max vector using first input polarity mask.
>> 6939:   vpsign_extend_dq(etype, xtmp4, src1, vlen_enc);
> 
> Sign extend to lower bits not needed as blend uses msbit only.

Original vector is has double / quad word lanes which are being blended using byte level mask, sign extension will ensure that sign bit is propagated to MSB bits of each constituent byte mask corresponding double / quad word source lane.

> src/hotspot/cpu/x86/x86.ad line 1953:
> 
>> 1951:        if (UseAVX < 1 || size_in_bits < 128 || (size_in_bits == 512 && !VM_Version::supports_avx512bw())) {
>> 1952:          return false;
>> 1953:        }
> 
> UseAVX < 1 could be written as UseAVX == 0. Could we not do register version for size_in_bit < 128?

I get your point, but constraints ensure we only address cases with vector size >= 128 bit in this patch..

> src/hotspot/cpu/x86/x86.ad line 10635:
> 
>> 10633: %}
>> 10634: 
>> 10635: instruct saturating_unsigned_add_reg_avx(vec dst, vec src1, vec src2, vec xtmp1, vec xtmp2, vec xtmp3, vec xtmp4)
> 
> Should the temp here and all the places related to !avx512vl() be legVec instead of vec?

Predicate already has AVX512VL check and so does dynamic register classes associated with its operands.

> src/hotspot/cpu/x86/x86.ad line 10656:
> 
>> 10654:   match(Set dst (SaturatingSubVI src1 src2));
>> 10655:   match(Set dst (SaturatingSubVL src1 src2));
>> 10656:   effect(TEMP ktmp);
> 
> This needs TEMP dst as well.

There is no use of either of the source operands after assignment to dst in the macro assembly routine.

> src/java.base/share/classes/java/lang/Byte.java line 647:
> 
>> 645:      */
>> 646:     public static byte subSaturating(byte a, byte b) {
>> 647:         byte res = (byte)(a - b);
> 
> Could we not do subSaturating as an int operation on similar lines as addSaturating?

Yes, core libs also have {add/subtract}Exact API which instead of saturating over / underflowing values throws ArithmeticException. Streamlining overflow checks for saturating long operations on the same lines to address Joe's concerns on new constants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740820063
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740819360
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740823487
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740823011
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740819742
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740819629
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740822270
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740821085

From jbhateja at openjdk.org  Mon Sep  2 12:21:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 2 Sep 2024 12:21:00 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <Vv7j1ge8HBVY0I0nVq07uuSatyIwmQaqrk47grgTqJo=.2a89c118-3ed2-499e-92a5-e4fa006e32aa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
 <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
 <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>
 <QfgwwVXsYjjdGR65TfJJZjAXTS81OUyP-WOvWRRmfBk=.9e3ff6c8-201e-4b0e-93a2-9de753904279@github.com>
 <agai02WarwvrKhvnB04UiBvmolhjJaMc6y8xk0xjytU=.def3d32b-7250-4a53-a4d3-679997edd22c@github.com>
 <Vv7j1ge8HBVY0I0nVq07uuSatyIwmQaqrk47grgTqJo=.2a89c118-3ed2-499e-92a5-e4fa006e32aa@github.com>
Message-ID: <seDDAZ9Pn8pR-EIilIWYUXL28wkKiuzauvMoa-qLZd0=.c6ac4085-53a9-4651-b4ca-1d8f1e71ba7d@github.com>

On Wed, 28 Aug 2024 16:05:45 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Wonder if it would have been simpler if we added unsigned vector operators like Op_SaturatingUnsignedAddVB etc. We are not adding unsigned data types to Java, only supporting unsigned (saturating) operations on existing signed integral types.
>
> If the aim is to reduce the number of nodes, we could merge the Op_SaturatingAddVB, Op_SaturatingAddVS, Op_SaturatingAddVI, and Op_SaturatingAddVL into one Op_SaturatingAddV. Likewise for unsigned saturating add into Op_SaturatingUnsignedAddV.

Hey @sviswa7,  our concern was around value ranges of new unsigned scalar type, which as mentioned will be addressed when I support intrinsification of new core lib APIs and associated range constraining / folding optimization in a follow up patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1740817837

From jwaters at openjdk.org  Mon Sep  2 12:36:20 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 2 Sep 2024 12:36:20 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings
In-Reply-To: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
Message-ID: <3fqsUh2hpNUSuZdV5ABE_B39ETgruLRO5jnEYzWAN18=.b8d42416-3e95-46ff-beac-545bad8207ef@github.com>

On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>     char exePath[PATH_MAX];
>          ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>     int ret;
>         ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>     char fn[32];
>          ^
> 
> This seems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)

Ah, the joys of supporting a platform that isn't covered by the Actions compile and test safety net :)

Looks Good, with that aside

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2275532558

From mbaesken at openjdk.org  Mon Sep  2 12:36:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Sep 2024 12:36:20 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings
In-Reply-To: <3fqsUh2hpNUSuZdV5ABE_B39ETgruLRO5jnEYzWAN18=.b8d42416-3e95-46ff-beac-545bad8207ef@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <3fqsUh2hpNUSuZdV5ABE_B39ETgruLRO5jnEYzWAN18=.b8d42416-3e95-46ff-beac-545bad8207ef@github.com>
Message-ID: <rblaDQEkoGH2wggNxqD9RVrHxFMH4r-PzK3Rs5vu8iY=.160fb332-afb7-4596-839d-8f3e72b66218@github.com>

On Mon, 2 Sep 2024 12:30:43 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Ah, the joys of supporting a platform that isn't covered by the Actions compile and test safety net :)

A Linux/clang build in the GHA would have probably shown at least a part of those errors.

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

PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2324651948

From liach at openjdk.org  Mon Sep  2 13:17:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 13:17:19 GMT
Subject: RFR: 8339368: Switch targets are not inflated in CodeModel if no
 StackMap
In-Reply-To: <H1d-KYsWJtng8JttZ8PQMVhZ1iIZ5usGVN5rKBRw6-M=.479358c9-0a3e-44aa-af7c-bb53cf2e810d@github.com>
References: <H1d-KYsWJtng8JttZ8PQMVhZ1iIZ5usGVN5rKBRw6-M=.479358c9-0a3e-44aa-af7c-bb53cf2e810d@github.com>
Message-ID: <kWGkLypA-EnWKZHqP2Cxlz95zxTyo51z7BS3XoGyLD0=.e2fc381c-53d5-4b60-bb69-aebbebb06421@github.com>

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

> ClassFile API use an alternate labels inflation method for class versions < 50 (where StackMapTable attribute is optional).
> The alternate method missed label inflation of lookup switch and table switch instructions.
> This patch fixes the label inflation method for for class versions < 50 and adds relevant test.
> 
> Please review.
> 
> Thanks,
> Adam

Thanks for this fix.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20810#pullrequestreview-2275639509

From mbaesken at openjdk.org  Mon Sep  2 13:25:51 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Sep 2024 13:25:51 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
Message-ID: <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>

> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>     char exePath[PATH_MAX];
>          ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>     int ret;
>         ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>     char fn[32];
>          ^
> 
> This seems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)

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

  adjust indentation in X11Color.c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20812/files
  - new: https://git.openjdk.org/jdk/pull/20812/files/0fca9ee0..082e6f60

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

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

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

From mbaesken at openjdk.org  Mon Sep  2 13:25:51 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Sep 2024 13:25:51 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings
In-Reply-To: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
Message-ID: <vbj9c3LpVYYG2GLjA7N4HgzKqztoy0igl_xvgFGUqPw=.a6b60be8-47df-4eb8-8704-81fc50ecc57a@github.com>

On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>     char exePath[PATH_MAX];
>          ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>     int ret;
>         ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>     char fn[32];
>          ^
> 
> This seems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)

macos-aarch64 failure seems to be https://bugs.openjdk.org/browse/JDK-8338712 (unrelated)

Hi Christoph and Julian, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2324745071
PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2324752339

From mbaesken at openjdk.org  Mon Sep  2 13:25:51 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Sep 2024 13:25:51 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <21Qc2WxZ7rcyk2WSogCUe3L2ZMbctnz7QF7XdorWFn0=.6b90a395-9f9b-4408-a05f-abb0e5008b72@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <21Qc2WxZ7rcyk2WSogCUe3L2ZMbctnz7QF7XdorWFn0=.6b90a395-9f9b-4408-a05f-abb0e5008b72@github.com>
Message-ID: <InkisUA7qXB26MpQ1oZfmlqkAYw9AZftlkVIqCiP_3c=.5ffff1a8-6169-4cb4-a2fb-f74d03dd0132@github.com>

On Mon, 2 Sep 2024 12:17:57 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/common/awt/X11Color.c line 1236:
> 
>> 1234:     for (int i = 0; i < num_colors; i++)
>> 1235:         alloc_col (awt_display, awtData->awt_cmap, red (rgbColors [i]),
>> 1236:                      green (rgbColors [i]), blue (rgbColors [i]), -1,
> 
> Seems like indentation here could be improved a bit.

Agree, I adjust this in another commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1740919406

From redestad at openjdk.org  Mon Sep  2 14:06:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 2 Sep 2024 14:06:43 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v4]
In-Reply-To: <vinSCh5ftue567kq_iaLUp1WG84KMI6wgN_jcFOq8kg=.d0756d5a-99cb-4934-9da9-c2904b2b5b8d@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <vinSCh5ftue567kq_iaLUp1WG84KMI6wgN_jcFOq8kg=.d0756d5a-99cb-4934-9da9-c2904b2b5b8d@github.com>
Message-ID: <z7bvQMJIvfbE23QAGTc18axkSmYNn18F9XbWmUZtApI=.952b70c1-d03b-478b-8443-f70ba69c4e7f@github.com>

On Fri, 30 Aug 2024 19:39:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize Utf8EntryImpl#writeTo(UTF)

So this small win now comes from reserving space up front (possibly excessively so) and writing directly to the byte-array, avoiding excessive `reserveSpace` calls - right? A bit underwhelming, maybe.

I also think there's a pre-existing bug here: the max length _in bytes_ of a UTF-8 classfile entry is 65535, but we're checking `s.length() < 65535` (which is only correct if the string is ascii). Perhaps this code need to do what `DataOutputStream.writeUTF(String)` does and calculate the length in bytes up front.

Did you profile the microbenchmark to see that the `Utf8EntryImpl#writeTo` is actually a bottleneck in this test? I took a peek and it seems to be doing mostly other things, and when I've run this test a few times it seems there's quite a bit of run-to-run variance. I think we need a more focused microbenchmark to say anything about the writeUTF method.

A quick, easy and portable profiling technique that doesn't depend on any external tools: `make test TEST="micro:Utf8EntryWriteTo" MICRO="OPTIONS=-p charType=ascii -f 1 -i 50 -prof jfr"` (bumping -i to get enough samples, -f 1 since the test runner would overwrite recordings from multiple forks). 

The run will just take a recording and print something like:

JFR profiler results:
  <path>/org.openjdk.bench.java.lang.classfile.Utf8EntryWriteTo.writeTo-AverageTime-charType-ascii/profile.jfr


Then use JMC or the built-in jfr tool to inspect the recording. E.g. `build/<arch>/images/jdk/bin/jfr view hot-methods <path>/org.openjdk.bench.java.lang.classfile.Utf8EntryWriteTo.writeTo-AverageTime-charType-ascii//profile.jfr` is quite useful:

                                          Java Methods that Executes the Most

Method                                                                                                  Samples Percent
------------------------------------------------------------------------------------------------------- ------- -------
jdk.internal.classfile.impl.SplitConstantPool.entryByIndex(int)                                             280   8,03%
jdk.internal.classfile.impl.RawBytecodeHelper.rawNext()                                                     263   7,54%
jdk.internal.util.ArraysSupport.unsignedHashCode(int, byte[], int, int)                                     215   6,17%
jdk.internal.classfile.impl.EntryMap.firstToken(int)                                                        210   6,02%
jdk.internal.classfile.impl.StackMapGenerator.detectFrameOffsets()                                          165   4,73%
java.lang.String.equals(Object)                                                                             165   4,73%
jdk.internal.classfile.impl.SplitConstantPool.findEntry(int, AbstractPoolEntry, AbstractPoolEntry)          109   3,13%
jdk.internal.classfile.impl.SplitConstantPool.findEntry(int, AbstractPoolEntry)                             104   2,98%
jdk.internal.classfile.impl.StackMapGenerator.processMethod()                                                85   2,44%
java.lang.classfile.constantpool.ConstantPoolBuilder.nameAndTypeEntry(String, MethodTypeDesc)                83   2,38%
java.lang.String.<init>(byte[], byte)                                                                        76   2,18%
jdk.internal.classfile.impl.SplitConstantPool.map()                                                          72   2,07%
jdk.internal.classfile.impl.BufWriterImpl.reserveSpace(int)                                                  69   1,98%
jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl.toString()                                       64   1,84%
jdk.internal.classfile.impl.SplitConstantPool.tryFindUtf8(int, String)                                       63   1,81%
jdk.internal.classfile.impl.StackMapGenerator.processInvokeInstructions(...)                                 57   1,64%
java.nio.Buffer.checkIndex(int)                                                                              54   1,55%
java.lang.classfile.constantpool.ConstantPoolBuilder.classEntry(ClassDesc)                                   53   1,52%
jdk.internal.classfile.impl.SplitConstantPool$2.fetchElement(int)                                            52   1,49%
jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl.hashCode()                                       49   1,41%
java.lang.classfile.CodeBuilder.invoke(Opcode, ClassDesc, String, MethodTypeDesc, boolean)                   48   1,38%
jdk.internal.classfile.impl.AbstractPoolEntry.maybeClone(ConstantPoolBuilder, PoolEntry)                     46   1,32%
jdk.internal.classfile.impl.SplitConstantPool.maybeCloneUtf8Entry(Utf8Entry)                                 45   1,29%
jdk.internal.classfile.impl.StackMapGenerator.processBlock(RawBytecodeHelper)                                40   1,15%
java.util.Arrays.copyOfRange(byte[], int, int)                                                               40   1,15%```

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2322975213
PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2323337370

From duke at openjdk.org  Mon Sep  2 14:06:43 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 2 Sep 2024 14:06:43 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v5]
In-Reply-To: <J4v8jPzP_d6JROVSxm4mJucYt-X_8Yr4B9sxI0Nen0E=.6fc187d5-c945-4276-ab7d-ba333b5a42f7@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <J4v8jPzP_d6JROVSxm4mJucYt-X_8Yr4B9sxI0Nen0E=.6fc187d5-c945-4276-ab7d-ba333b5a42f7@github.com>
Message-ID: <KeBLUfwst-WS8zlYuRBRdTZwixWF_wpsV660alo-tHw=.a09f80b7-4fcf-4fb1-9fe3-63ed686808b1@github.com>

On Mon, 2 Sep 2024 14:03:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> 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 21 additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/StringCoding.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - vectorized countGreaterThanZero
>  - add comments
>  - optimization for none-ascii latin1
>  - Revert "vectorized countGreaterThanZero"
>    
>    This reverts commit 88a77722c8f5401ac28572509d6a08b3e88e8e40.
>  - vectorized countGreaterThanZero
>  - copyright
>  - use JLA if length < 256
>  - fix utf_len error
>  - code style
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/66682133...2a36b443

src/java.base/share/classes/java/lang/StringCoding.java line 55:

> 53:         int i = off;
> 54:         for (; i < limit; i += 8) {
> 55:             long v = UNSAFE.getLong(ba, i + ARRAY_BYTE_BASE_OFFSET);

Since?`value` is?a?`byte[]`, `UNSAFE.getLong` could?get?bytes outside?the?array.

Also, that?s?not even?considering the?fact?that the?address might?not?even be?`long`?aligned for?`(off?%?8)?!?=?0` or?`(off?%?8)?!?=?4`, depending?on the?array header?size (see?[JDK?8139457] and?[JDK?8314882]).

[JDK?8139457]: https://bugs.openjdk.org/browse/JDK-8139457
[JDK?8314882]: https://bugs.openjdk.org/browse/JDK-8314882

Suggestion:

        for (int end = limit - 7; i < end; i += 8) {
            long v = UNSAFE.getLongUnaligned(ba, i + ARRAY_BYTE_BASE_OFFSET);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1740188542

From swen at openjdk.org  Mon Sep  2 14:06:42 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 14:06:42 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v5]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <J4v8jPzP_d6JROVSxm4mJucYt-X_8Yr4B9sxI0Nen0E=.6fc187d5-c945-4276-ab7d-ba333b5a42f7@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

 - Update src/java.base/share/classes/java/lang/StringCoding.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - vectorized countGreaterThanZero
 - add comments
 - optimization for none-ascii latin1
 - Revert "vectorized countGreaterThanZero"
   
   This reverts commit 88a77722c8f5401ac28572509d6a08b3e88e8e40.
 - vectorized countGreaterThanZero
 - copyright
 - use JLA if length < 256
 - fix utf_len error
 - code style
 - ... and 11 more: https://git.openjdk.org/jdk/compare/66682133...2a36b443

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/34aab42d..2a36b443

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

  Stats: 4359 lines in 151 files changed: 2931 ins; 319 del; 1109 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From swen at openjdk.org  Mon Sep  2 14:06:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 14:06:43 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v4]
In-Reply-To: <vinSCh5ftue567kq_iaLUp1WG84KMI6wgN_jcFOq8kg=.d0756d5a-99cb-4934-9da9-c2904b2b5b8d@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <vinSCh5ftue567kq_iaLUp1WG84KMI6wgN_jcFOq8kg=.d0756d5a-99cb-4934-9da9-c2904b2b5b8d@github.com>
Message-ID: <Ps4m8V_V94adHLPnabhgGbinCIf6IbbJ-Zzifh4V0nc=.6fd7c9c7-6aa3-4997-89ff-6cafa97e33b9@github.com>

On Fri, 30 Aug 2024 19:39:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize Utf8EntryImpl#writeTo(UTF)

Below are the performance numbers running on a MacBook M1, With the option `Xint -XX:TieredStopAtLevel=1`, the overall performance is improved by about 1%, and without the option, the performance is improved by about 4%.

## 1. TieredStopAtLevel=1

### 1.1 Script

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

# baseline
git checkout d53c9f153463d2a1e36f4157574d890763edbf0f
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout f055f3fda508873241f28621cbc71ff19874e5ca
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"


### 1.2 Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt     Score   Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  1376.779 ? 4.304  us/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1384.241 ? 2.586  us/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1423.933 ? 4.316  us/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  1513.636 ? 7.290  us/op

+# current
+Benchmark                   (charType)  Mode  Cnt     Score   Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  1361.663 ? 2.395  us/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1362.041 ? 4.400  us/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1398.706 ? 3.941  us/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  1475.106 ? 3.335  us/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 1376.779 | 1361.663 | 1.11% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 1384.241 | 1362.041 | 1.63% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 1423.933 | 1398.706 | 1.80% |
| Utf8EntryWriteTo.writeTo | emoji | 1513.636 | 1475.106 | 2.61% |


## 2. Non-JVM Options

### 2.1 Script

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

# baseline
git checkout d53c9f153463d2a1e36f4157574d890763edbf0f
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"

# current
git checkout f055f3fda508873241f28621cbc71ff19874e5ca
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"


## 2.2 Performance Numbers

-# baseline
-Benchmark                   (charType)  Mode  Cnt   Score   Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  20.013 ? 0.291  us/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  19.956 ? 0.312  us/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  20.294 ? 0.297  us/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  20.444 ? 0.343  us/op

+# current
+Benchmark                   (charType)  Mode  Cnt   Score   Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  19.161 ? 0.750  us/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  18.967 ? 0.225  us/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  19.474 ? 0.362  us/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  19.743 ? 0.474  us/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 20.013 | 19.161 | 4.45% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 19.956 | 18.967 | 5.21% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 20.294 | 19.474 | 4.21% |
| Utf8EntryWriteTo.writeTo | emoji | 20.444 | 19.743 | 3.55% |

I reverted the use of JLA#isLatin1GreaterThanZero, Using JLA#isLatin1GreaterThanZero is beneficial to performance improvement, but a threshold value is needed to avoid the possibility of slowdown caused by cache miss due to two loops. Liach mentioned above that the performance regression of jetty startup may be caused by this. Currently, this threshold is set to 256, which may be larger.

Here are the performance numbers on a MacBook M1 Pro (aarch64) and Aliyun ECS C8i (Intel x64). When the `TieredStopAtLevel=1` option is configured, the performance is improved by about 2. Without the option, the performance of the MacBook M1 Pro is improved by about 7%, and the performance under Linux Intel x64 is improved by about 0.7%.

## 1. TieredStopAtLevel=1

### 1.1 Script

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

# baseline
git checkout d53c9f153463d2a1e36f4157574d890763edbf0f
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout a773005cee59d1ffae494ebbe2a552b15c30a5a6
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"


### 1.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt     Score   Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  1374.766 ? 1.419  us/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1382.998 ? 4.286  us/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1425.600 ? 5.542  us/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  1510.438 ? 4.431  us/op

+# current
+Benchmark                   (charType)  Mode  Cnt     Score   Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  1345.666 ? 1.985  us/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1351.628 ? 2.796  us/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1388.559 ? 3.768  us/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  1463.979 ? 4.763  us/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 1374.766 | 1345.666 | 2.16% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 1382.998 | 1351.628 | 2.32% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 1425.600 | 1388.559 | 2.67% |
| Utf8EntryWriteTo.writeTo | emoji | 1510.438 | 1463.979 | 3.17% |

### 1.3 Aliyun ECS Performance Numbers
* Linux, Intel x64 cpu


-# baseline
-Benchmark                   (charType)  Mode  Cnt     Score    Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  1641.666 ? 22.443  us/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1642.376 ? 10.525  us/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1695.354 ?  9.464  us/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  1806.769 ? 11.571  us/op

+# current
+Benchmark                   (charType)  Mode  Cnt     Score    Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  1611.783 ? 14.023  us/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1630.246 ? 45.576  us/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1659.347 ?  7.682  us/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  1763.372 ? 13.568  us/op



|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 1641.666 | 1611.783 | 1.85% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 1642.376 | 1630.246 | 0.74% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 1695.354 | 1659.347 | 2.17% |
| Utf8EntryWriteTo.writeTo | emoji | 1806.769 | 1763.372 | 2.46% |


### 2.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt     Score   Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  1374.766 ? 1.419  us/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1382.998 ? 4.286  us/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1425.600 ? 5.542  us/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  1510.438 ? 4.431  us/op

+# current
+Benchmark                   (charType)  Mode  Cnt     Score   Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  1345.666 ? 1.985  us/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1351.628 ? 2.796  us/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1388.559 ? 3.768  us/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  1463.979 ? 4.763  us/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 19.960 | 18.637 | 7.10% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 19.973 | 18.669 | 6.98% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 20.153 | 18.794 | 7.23% |
| Utf8EntryWriteTo.writeTo | emoji | 20.688 | 19.001 | 8.88% |


### 2.3 Aliyun ECS Performance Numbers
* Linux, Intel x64 cpu

-# baseline
-Benchmark                   (charType)  Mode  Cnt   Score   Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  21.146 ? 0.649  us/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  21.232 ? 0.248  us/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  21.358 ? 0.216  us/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  21.381 ? 0.599  us/op

+# current
+Benchmark                   (charType)  Mode  Cnt   Score   Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  21.000 ? 0.181  us/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  21.141 ? 0.520  us/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  21.381 ? 0.281  us/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  21.436 ? 0.390  us/op



|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 21.146 | 21.000 | 0.70% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 21.232 | 21.141 | 0.43% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 21.358 | 21.381 | -0.11% |
| Utf8EntryWriteTo.writeTo | emoji | 21.381 | 21.436 | -0.26% |

![image](https://github.com/user-attachments/assets/f116e89a-c784-4c20-bd10-843f792c5265)

The two red boxes in the figure are the optimization targets of PR #20772 and PR #20756

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2322789508
PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2323063113
PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2323372154

From swen at openjdk.org  Mon Sep  2 14:10:48 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 14:10:48 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions
Message-ID: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>

BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder

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

Commit messages:
 - suggestion from @liach
 - copyright
 - direct call
 - Break up large methods into small ones, so that the code size is less than 325

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

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

From swen at openjdk.org  Mon Sep  2 14:10:48 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 14:10:48 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions
In-Reply-To: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
Message-ID: <LxwtvzlShPExqPL22OBaNCNDhF16cu0nBNkPerWnVQA=.824d9eb5-87c3-4cd2-9279-51918b4241d5@github.com>

On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder

@cl4es @liach Is there a better way to ensure that Opcode has completed type initialization before calling arrayLoad?

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

PR Comment: https://git.openjdk.org/jdk/pull/20739#issuecomment-2315223609

From liach at openjdk.org  Mon Sep  2 14:10:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 14:10:48 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions
In-Reply-To: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
Message-ID: <n5k3qBt8YJnGK1PN1dgFSaXOZwTUeM5l82eF9ku2H_s=.ca463e12-383e-45a5-8924-75a5b109b788@github.com>

On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder

src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 61:

> 59:         return switch (tk) {
> 60:             case INT, SHORT, BYTE, CHAR, BOOLEAN
> 61:                            -> iload(slot);

Can you do

switch (tk.asLoadable()) {
    case INT      -> iload(slot);

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 1479:

> 1477: 
> 1478:     @Override
> 1479:     public CodeBuilder iload(int slot) {

Can you put them in the same order they are declared in `CodeBuilder`, like `iload` between `iinc` and `imul`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20739#discussion_r1740895441
PR Review Comment: https://git.openjdk.org/jdk/pull/20739#discussion_r1740898004

From swen at openjdk.org  Mon Sep  2 14:10:48 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 14:10:48 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions
In-Reply-To: <n5k3qBt8YJnGK1PN1dgFSaXOZwTUeM5l82eF9ku2H_s=.ca463e12-383e-45a5-8924-75a5b109b788@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
 <n5k3qBt8YJnGK1PN1dgFSaXOZwTUeM5l82eF9ku2H_s=.ca463e12-383e-45a5-8924-75a5b109b788@github.com>
Message-ID: <L9jxHnaEgtwHFCY3NSE54WEjDUObvnkSZFMy3PXYLOs=.531dfb49-fc68-4686-a337-69b057423322@github.com>

On Mon, 2 Sep 2024 13:02:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 61:
> 
>> 59:         return switch (tk) {
>> 60:             case INT, SHORT, BYTE, CHAR, BOOLEAN
>> 61:                            -> iload(slot);
> 
> Can you do
> 
> switch (tk.asLoadable()) {
>     case INT      -> iload(slot);

I'm not sure if that's better, because there's a getField and branch in the implementation of asLoadable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20739#discussion_r1740969683

From liach at openjdk.org  Mon Sep  2 14:27:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 14:27:19 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions
In-Reply-To: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
Message-ID: <RsRIAMtdVtUje3RO6v_uOHz90MbS-wd9UdKRNlBul_k=.fdcd2fd6-06f1-458b-8e14-b749bc96eaab@github.com>

On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 1200:

> 1198: 
> 1199:     @Override
> 1200:     public CodeBuilder lload(int slot) {

Uh, I mean each of the method is inserted to our existing override list by alphabetical order instead of inserting everything to the same place at once

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20739#discussion_r1740997023

From liach at openjdk.org  Mon Sep  2 14:31:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 14:31:18 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions
In-Reply-To: <L9jxHnaEgtwHFCY3NSE54WEjDUObvnkSZFMy3PXYLOs=.531dfb49-fc68-4686-a337-69b057423322@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
 <n5k3qBt8YJnGK1PN1dgFSaXOZwTUeM5l82eF9ku2H_s=.ca463e12-383e-45a5-8924-75a5b109b788@github.com>
 <L9jxHnaEgtwHFCY3NSE54WEjDUObvnkSZFMy3PXYLOs=.531dfb49-fc68-4686-a337-69b057423322@github.com>
Message-ID: <nBcM-1ntB5FYDYJfOt-bmACdqPnShBO5OdtHAgZfVlI=.772e7d10-9d22-4367-9c31-21230c1fd845@github.com>

On Mon, 2 Sep 2024 14:01:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 61:
>> 
>>> 59:         return switch (tk) {
>>> 60:             case INT, SHORT, BYTE, CHAR, BOOLEAN
>>> 61:                            -> iload(slot);
>> 
>> Can you do
>> 
>> switch (tk.asLoadable()) {
>>     case INT      -> iload(slot);
>
> I'm not sure if that's better, because there's a getField and branch in the implementation of asLoadable

Logically I think `asLoadable` is clearer and reduces switch size.
And enum `ordinal` field is already constant-folded: https://bugs.openjdk.org/browse/JDK-81612454
So it can be elided by JIT if the enum argument is constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20739#discussion_r1741000967

From liach at openjdk.org  Mon Sep  2 14:47:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 14:47:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v5]
In-Reply-To: <J4v8jPzP_d6JROVSxm4mJucYt-X_8Yr4B9sxI0Nen0E=.6fc187d5-c945-4276-ab7d-ba333b5a42f7@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <J4v8jPzP_d6JROVSxm4mJucYt-X_8Yr4B9sxI0Nen0E=.6fc187d5-c945-4276-ab7d-ba333b5a42f7@github.com>
Message-ID: <bS2rRyixvDbcDMBaBPboouRX7C2RRMKjLQBaA4lV95c=.73b438a8-599d-4bc1-8de0-83b9f81ac733@github.com>

On Mon, 2 Sep 2024 14:06:42 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> 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 21 additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/StringCoding.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - vectorized countGreaterThanZero
>  - add comments
>  - optimization for none-ascii latin1
>  - Revert "vectorized countGreaterThanZero"
>    
>    This reverts commit 88a77722c8f5401ac28572509d6a08b3e88e8e40.
>  - vectorized countGreaterThanZero
>  - copyright
>  - use JLA if length < 256
>  - fix utf_len error
>  - code style
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/e43c4655...2a36b443

test/micro/org/openjdk/bench/java/lang/classfile/Utf8EntryWriteTo.java line 85:

> 83:         for (int i = 0; i < constants.length; i++) {
> 84:             constants[i] = s.repeat(32);
> 85:         }

I think this micro is testing too much irrelevant parts of classfile generation. I would recommend these changes:
1. Compute a `ConstantPoolBuilder` in `setup`, like:

ConstantPoolBuilder poolBuilder;
ClassEntry thisClass;



poolBuilder = ConstantPoolBuilder.of();
thisClass = poolBuilder.classEntry(CLASS_DESC);
for (var s : constants) {
    poolBuilder.utf8Entry(s);
}

3. In benchmark, test like:

@Benchmark
public byte[] writeTo() {
    return cf.build(thisClass, poolBuilder, clb -> {});
}

This should eradicate the cost around method or instruction generation while still ensuring the constants are written to the class file as part of the constant pool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741018079

From swen at openjdk.org  Mon Sep  2 14:50:33 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 14:50:33 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions [v2]
In-Reply-To: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
Message-ID: <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>

> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder

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

  suggestion from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20739/files
  - new: https://git.openjdk.org/jdk/pull/20739/files/22565c58..58a15b38

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

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

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

From liach at openjdk.org  Mon Sep  2 14:55:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 14:55:22 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions [v2]
In-Reply-To: <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
 <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>
Message-ID: <aLviTAcim7VJfbeHas-rb9lAh2oJES3fQLiKqjLAnuY=.efe09f87-0bb6-4eea-bc25-604317931cce@github.com>

On Mon, 2 Sep 2024 14:50:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20739#pullrequestreview-2275839135

From swen at openjdk.org  Mon Sep  2 15:11:56 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 15:11:56 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v6]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <isat3WC1tHJr7gLa8jl2PdjcX2G0ZIoPur1ihUU8EKk=.6e32379f-f7b1-4510-a8dd-01ad4cc2cfb5@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  suggestion from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/2a36b443..656b0f65

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

  Stats: 42 lines in 1 file changed: 8 ins; 29 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From liach at openjdk.org  Mon Sep  2 15:15:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Sep 2024 15:15:20 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v6]
In-Reply-To: <isat3WC1tHJr7gLa8jl2PdjcX2G0ZIoPur1ihUU8EKk=.6e32379f-f7b1-4510-a8dd-01ad4cc2cfb5@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <isat3WC1tHJr7gLa8jl2PdjcX2G0ZIoPur1ihUU8EKk=.6e32379f-f7b1-4510-a8dd-01ad4cc2cfb5@github.com>
Message-ID: <Krsg8mgwXtxElsZyVl8ZKrKTLk7DOYmzWNU4QsyGmN8=.f2cc37ee-a881-489e-9abd-4dce7dee558d@github.com>

On Mon, 2 Sep 2024 15:11:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

test/micro/org/openjdk/bench/java/lang/classfile/Utf8EntryWriteTo.java line 98:

> 96:     @Benchmark
> 97:     public void writeTo(Blackhole bh) {
> 98:         ClassFile.of()

You need to either return the build result or bh.consume the build result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741053939

From swen at openjdk.org  Mon Sep  2 15:20:51 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 15:20:51 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v7]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <sLvsUKEHW_VNnMN7jcuKk3rTXLA3B92DeRTBxEzpgCo=.c63dcbb4-7a8a-41b4-aa78-ff221e8a8c33@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  suggestion from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/656b0f65..89bd2009

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

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

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

From swen at openjdk.org  Mon Sep  2 15:27:59 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 15:27:59 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v8]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <5GFaqWWuQD1kOUCucyVy28pgJsxDe1AgrzGTwWxlwLw=.1042a2fc-6204-4f93-a4b2-93e57a6579b6@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/89bd2009..99143fdb

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

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

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

From swen at openjdk.org  Mon Sep  2 15:45:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 15:45:20 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v3]
In-Reply-To: <rLC7afbHFALMLmjgpBKxwTBL4nJPDQJsZhTFVty6-DQ=.d91b822f-39f3-4e46-a0c5-77e0deabd701@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <3G9eHYj2OVrhr62Jrle5X4_3Wj98YKTtJeABYo8bgfA=.d60e0485-dfe2-4f69-bb81-495f3b79365b@github.com>
 <rLC7afbHFALMLmjgpBKxwTBL4nJPDQJsZhTFVty6-DQ=.d91b822f-39f3-4e46-a0c5-77e0deabd701@github.com>
Message-ID: <Y9TgU9klbLylyZA5gHronj4IIpj6qBc6bW5w3aXO6xQ=.dbd617d8-70b8-4f4f-865c-ae854c0aee23@github.com>

On Fri, 30 Aug 2024 18:46:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggestions from @cl4es, rename hasNegativeOrZeros to isLatin1GreaterThanZero
>
> If a non-ascii is in the middle or the end of a string, this patch may add an overhead. Offline benchmark results show that this actually brings a regression in the startup of a jetty server.

Thanks to @liach for providing new ideas for benchmarking. Here are the new performance data

## 1. TieredStopAtLevel=1

### 1.1 Script

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

# baseline
git checkout 12550c3ea58a6405de21cc185fa972378b534120
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout 99143fdb3a11140d5c9f067c144629def344666d
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"



### 1.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  26818.441 ? 476.844  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  33001.261 ?  78.130  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  40134.337 ? 103.220  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  58745.488 ? 205.561  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  10795.072 ? 254.952  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  14661.640 ?  64.254  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  17129.657 ? 194.146  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  24167.056 ? 319.348  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 26818.441 | 10795.072 | 148.43% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 33001.261 | 14661.640 | 125.09% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 40134.337 | 17129.657 | 134.30% |
| Utf8EntryWriteTo.writeTo | emoji | 58745.488 | 24167.056 | 143.08% |


## 2. Non-JVM Options

### 2.1 Script

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

# baseline
git checkout 12550c3ea58a6405de21cc185fa972378b534120
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"

# current
git checkout 99143fdb3a11140d5c9f067c144629def344666d
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"


### 2.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt    Score   Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  268.824 ? 2.834  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  308.376 ? 1.581  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  343.579 ? 1.331  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  463.350 ? 2.090  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt    Score     Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  139.114 ?   0.873  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  158.509 ?   0.772  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  170.437 ?   2.442  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  268.832 ? 112.823  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 268.824 | 139.114 | 93.24% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 308.376 | 158.509 | 94.55% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 343.579 | 170.437 | 101.59% |
| Utf8EntryWriteTo.writeTo | emoji | 463.350 | 268.832 | 72.36% |

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2325008818

From andrew at openjdk.org  Mon Sep  2 16:05:23 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 2 Sep 2024 16:05:23 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
Message-ID: <fgXfd-S1Ew6vwNbw6O7qVz9rv_Cy24qcKgiApyHPSpE=.d481320a-ccf0-45f3-9cca-37d884915880@github.com>

On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim <duke at openjdk.org> wrote:

>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions

I can't review, as I ported the native code changes. On that note, can you make sure I'm credited as co-author using [/contributor](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor) please? 

i.e. /contributor add @gnu-andrew

You may want to also comment on [JDK-8185896](https://bugs.openjdk.org/browse/JDK-8185896) which is about adding Zip64 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2325035829

From rgiulietti at openjdk.org  Mon Sep  2 16:07:22 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 2 Sep 2024 16:07:22 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v4]
In-Reply-To: <j5OFnbrBkNWElnNhduuF-Q66chcQX-kAPJDMIL4McO0=.4fb57d80-91f1-447e-95dd-e3f22364d14d@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <j5OFnbrBkNWElnNhduuF-Q66chcQX-kAPJDMIL4McO0=.4fb57d80-91f1-447e-95dd-e3f22364d14d@github.com>
Message-ID: <Af3Of9eSjrD87uUQWOH3nVMhgygM2qtuIrPD8PGNM3s=.61cabd5d-1a29-41bb-b17c-591e8801a0b3@github.com>

On Sun, 1 Sep 2024 16:32:00 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code more clear

Here are a couple of preliminary work that can be done before delving into the details:
* If nothing else speaks against, new tests should use a testing framework, preferably [JUnit 5](https://junit.org/junit5/).
* In the OpenJDK we use [jtreg](https://openjdk.org/jtreg/) to run tests. This requires adding a few structured comment lines before the class declaration. For an example, see [ByteArrayConstructorTest](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigInteger/ByteArrayConstructorTest.java).
(See [jtreg tags](https://openjdk.org/jtreg/tag-spec.html) for full documentation.)
* I wonder if `MutableBigIntegerBox` can be reduced to just a set of accessors for the `MutableBigInteger` fields. Also, I guess that the benchmarks can be written to use the public class `BigInteger` to avoid having two copies of `MutableBigIntegerBox`.
* This PR is open since a couple of months now, so it would be a good thing to merge the branch `master` into the PR's branch.

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2325038239

From duke at openjdk.org  Mon Sep  2 16:19:01 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 2 Sep 2024 16:19:01 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

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

 - Merge branch 'openjdk:master' into patchLeftShift
 - Code more clear
 - Tests changes
 - Merge branch 'openjdk:master' into patchLeftShift
 - Removed trailing whitespace
 - MutableBigInteger.leftShift(int) optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/9231c600..87474ee9

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

  Stats: 35079 lines in 1101 files changed: 20749 ins; 9055 del; 5275 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

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

From duke at openjdk.org  Mon Sep  2 16:23:19 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 2 Sep 2024 16:23:19 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v4]
In-Reply-To: <Af3Of9eSjrD87uUQWOH3nVMhgygM2qtuIrPD8PGNM3s=.61cabd5d-1a29-41bb-b17c-591e8801a0b3@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <j5OFnbrBkNWElnNhduuF-Q66chcQX-kAPJDMIL4McO0=.4fb57d80-91f1-447e-95dd-e3f22364d14d@github.com>
 <Af3Of9eSjrD87uUQWOH3nVMhgygM2qtuIrPD8PGNM3s=.61cabd5d-1a29-41bb-b17c-591e8801a0b3@github.com>
Message-ID: <Uod9g7otB-aOKyYMFAnUHYL3MpcQ_8w-A-6rOJAr4lU=.37f30a7c-cb9d-4d59-bb01-261a5c98b122@github.com>

On Mon, 2 Sep 2024 16:04:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> * I wonder if `MutableBigIntegerBox` can be reduced to just a set of accessors for the `MutableBigInteger` fields. Also, I guess that the benchmarks can be written to use the public class `BigInteger` to avoid having two copies of `MutableBigIntegerBox`.

@rgiulietti The trouble is that the method to test is `MBI.leftShift()`, and `BigInteger.shiftLeft()` has its own implementation that does not use `MBI.leftShift()`, so i cannot see how this can be done.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2325059260

From rgiulietti at openjdk.org  Mon Sep  2 16:36:22 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 2 Sep 2024 16:36:22 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
Message-ID: <PVm1DVMVuASQRsgfL9msT0i2tFZqDHFdZnprDR2duWM=.04c75733-942b-44bb-b0d6-01febf7c7574@github.com>

On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Code more clear
>  - Tests changes
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Removed trailing whitespace
>  - MutableBigInteger.leftShift(int) optimization

Right, I didn't remember that `BigInteger` has its own implementation.

However, reducing `MutableBigIntegerBox` to just a bunch of accessors to use in the unit test and the benchmarks should still be possible. Then having two copies of that class should be less of an issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2325080149

From duke at openjdk.org  Mon Sep  2 16:45:18 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 2 Sep 2024 16:45:18 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <PVm1DVMVuASQRsgfL9msT0i2tFZqDHFdZnprDR2duWM=.04c75733-942b-44bb-b0d6-01febf7c7574@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <PVm1DVMVuASQRsgfL9msT0i2tFZqDHFdZnprDR2duWM=.04c75733-942b-44bb-b0d6-01febf7c7574@github.com>
Message-ID: <9qS4uleJBBDwxRFiea00kO5KD39gyqStxHR3IcHZ9Ec=.c35ad3c2-7392-4c79-8bd8-d7f0e70679f1@github.com>

On Mon, 2 Sep 2024 16:34:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Right, I didn't remember that `BigInteger` has its own implementation.
> 
> However, reducing `MutableBigIntegerBox` to just a bunch of accessors to use in the unit test and the benchmarks should still be possible. Then having two copies of that class should be less of an issue.

@rgiulietti Yes, however there is still the problem of how to get instances of `MutableBigInteger`, since it is not a public class...

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2325088461

From rgiulietti at openjdk.org  Mon Sep  2 17:19:22 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 2 Sep 2024 17:19:22 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
Message-ID: <qVJ-m9qQB_nVLzsVpyImgiXmZz229aCGJ-99_CsMNEw=.417c1cf0-4da3-401a-b8f3-bad838a011ff@github.com>

On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Code more clear
>  - Tests changes
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Removed trailing whitespace
>  - MutableBigInteger.leftShift(int) optimization

Yes, unfortunately there seems to be no way to reduce 2 x 163 lines to something more compact.
Luckily, that code is very simple.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2325121671

From redestad at openjdk.org  Mon Sep  2 17:21:26 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 2 Sep 2024 17:21:26 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v8]
In-Reply-To: <5GFaqWWuQD1kOUCucyVy28pgJsxDe1AgrzGTwWxlwLw=.1042a2fc-6204-4f93-a4b2-93e57a6579b6@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <5GFaqWWuQD1kOUCucyVy28pgJsxDe1AgrzGTwWxlwLw=.1042a2fc-6204-4f93-a4b2-93e57a6579b6@github.com>
Message-ID: <N_IGfnWXEZ0dsrLg_c4-60OTyUVp4JVKyUpKI6BKUfc=.2d86c9a4-1c6d-43eb-add8-41fe31860311@github.com>

On Mon, 2 Sep 2024 15:27:59 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

src/java.base/share/classes/java/lang/StringCoding.java line 39:

> 37: class StringCoding {
> 38:     private static final Unsafe UNSAFE = Unsafe.getUnsafe();
> 39:     private static final long POSITIVE_MASK = 0b1000000_1000000_1000000_1000000_1000000_1000000_1000000_1000000L;

Shouldn't this be `0b10000000_10000000_10000000_10000000_10000000_10000000_10000000_10000000L`? Either way this new method needs a sanity test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741141281

From mark.reinhold at oracle.com  Mon Sep  2 17:55:45 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Mon, 2 Sep 2024 17:55:45 +0000
Subject: New candidate JEP: 485: Stream Gatherers
Message-ID: <20240902175543.44781778E42@eggemoggin.niobe.net>

https://openjdk.org/jeps/485

  Summary: Enhance the Stream API to support custom intermediate
  operations.  This will allow stream pipelines to transform data in ways
  that are not easily achievable with the existing built-in intermediate
  operations.

- Mark

From redestad at openjdk.org  Mon Sep  2 18:32:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 2 Sep 2024 18:32:19 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v8]
In-Reply-To: <5GFaqWWuQD1kOUCucyVy28pgJsxDe1AgrzGTwWxlwLw=.1042a2fc-6204-4f93-a4b2-93e57a6579b6@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <5GFaqWWuQD1kOUCucyVy28pgJsxDe1AgrzGTwWxlwLw=.1042a2fc-6204-4f93-a4b2-93e57a6579b6@github.com>
Message-ID: <zcju0oB_1lpkiXifHu7AVjWBqi1X9t4eAl-r2ODDUjQ=.c00dc81a-4ee8-48cb-842b-c0a77dd81333@github.com>

On Mon, 2 Sep 2024 15:27:59 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Thanks for focusing the benchmark! 

Even with the suggested correction to the `Unsafe` vector loop, simplifying to just a simple scalar loop seem to be a net improvement across modes. I think this method could be turned into an intrinsic piggy-backing on countPositives if we find more leverage for it (`DataOutputStream::writeUTF` is a good candidate)

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2325185111

From mdoerr at openjdk.org  Mon Sep  2 20:11:18 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 2 Sep 2024 20:11:18 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
Message-ID: <ZcUB9uh3AjUhPp4M2MtgtwaId7ll5btcXcA9HJRHv_8=.8bab8619-163c-41fb-94ba-c1f06abd9862@github.com>

On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>>     char exePath[PATH_MAX];
>>          ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>>     int ret;
>>         ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>>     char fn[32];
>>          ^
>> 
>> This seems to be related to the recent make changes
>> 8339156: Use more fine-granular clang unused warnings
>> https://bugs.openjdk.org/browse/JDK-8339156
>> (we use clang too on AIX)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust indentation in X11Color.c

LGTM. Only minor nits.

src/java.base/unix/native/libjava/TimeZone_md.c line 63:

> 61: static const char *ETC_ENVIRONMENT_FILE = "/etc/environment";
> 62: #else
> 63: static char *isFileIdentical(char* buf, size_t size, char *pathname);

I think it should better be moved below `#if defined(__linux__) || defined(MACOSX)` instead of creating an else case.

src/java.desktop/unix/native/common/awt/X11Color.c line 1234:

> 1232: awt_allocate_systemrgbcolors (jint *rgbColors, int num_colors,
> 1233:                               AwtGraphicsConfigDataPtr awtData) {
> 1234:     for (int i = 0; i < num_colors; i++)

This requires C99. Is this ok for all platforms with all supported compilers?

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

PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2276121217
PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741226250
PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741228253

From davidalayachew at gmail.com  Mon Sep  2 21:58:46 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 2 Sep 2024 17:58:46 -0400
Subject: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <20240902175543.44781778E42@eggemoggin.niobe.net>
References: <20240902175543.44781778E42@eggemoggin.niobe.net>
Message-ID: <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>

Thanks. Glad to see this finally land. That slidingWindow and other related
functions are extremely powerful.

On Mon, Sep 2, 2024 at 3:13?PM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> https://openjdk.org/jeps/485
>
>   Summary: Enhance the Stream API to support custom intermediate
>   operations.  This will allow stream pipelines to transform data in ways
>   that are not easily achievable with the existing built-in intermediate
>   operations.
>
> - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240902/30499143/attachment.htm>

From ihse at openjdk.org  Mon Sep  2 22:35:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 2 Sep 2024 22:35:19 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <ZcUB9uh3AjUhPp4M2MtgtwaId7ll5btcXcA9HJRHv_8=.8bab8619-163c-41fb-94ba-c1f06abd9862@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
 <ZcUB9uh3AjUhPp4M2MtgtwaId7ll5btcXcA9HJRHv_8=.8bab8619-163c-41fb-94ba-c1f06abd9862@github.com>
Message-ID: <WKo4vV3Ao-mscoUBVy70CoxIn70Lr9u2lDSXwxkJaeg=.0e17dfa0-edc6-4d1f-b1e3-3ca19c87f37b@github.com>

On Mon, 2 Sep 2024 20:06:06 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/common/awt/X11Color.c line 1234:
> 
>> 1232: awt_allocate_systemrgbcolors (jint *rgbColors, int num_colors,
>> 1233:                               AwtGraphicsConfigDataPtr awtData) {
>> 1234:     for (int i = 0; i < num_colors; i++)
> 
> This requires C99. Is this ok for all platforms with all supported compilers?

Yes, we have C11 as minimum for the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741270798

From ihse at openjdk.org  Mon Sep  2 22:35:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 2 Sep 2024 22:35:20 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
Message-ID: <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>

On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>>     char exePath[PATH_MAX];
>>          ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>>     int ret;
>>         ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>>     char fn[32];
>>          ^
>> 
>> This seems to be related to the recent make changes
>> 8339156: Use more fine-granular clang unused warnings
>> https://bugs.openjdk.org/browse/JDK-8339156
>> (we use clang too on AIX)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust indentation in X11Color.c

src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744:

> 742:     int rslt = pthread_attr_init(&attr);
> 743:     if (rslt != 0) return;
> 744:     pthread_create(&thr, &attr, SplashScreenThread, (void *) splash);

You don't think it would be better to check the return code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741271285

From swen at openjdk.org  Mon Sep  2 22:49:59 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Sep 2024 22:49:59 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v9]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <oPpICt9ZGtiFg9NVmM8xTfCL-6DZJfGUBgfsMwBGdCs=.ebd3547c-0527-41ed-87bd-97884f698c30@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  bug fix countGreaterThanZero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/99143fdb..aca1c247

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

  Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From swen at openjdk.org  Tue Sep  3 00:38:40 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 00:38:40 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v10]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

 - code style
 - remove unsafe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/aca1c247..10cc1535

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

  Stats: 29 lines in 2 files changed: 0 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From swen at openjdk.org  Tue Sep  3 00:51:27 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 00:51:27 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v10]
In-Reply-To: <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
Message-ID: <L5Ng_5u6aLeWIzDz4seqyFjMdVmIkX1TH0LaLOqK_UM=.574c5c8c-4d17-4a2a-b8e1-d2eb5ad225ae@github.com>

On Tue, 3 Sep 2024 00:38:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - code style
>  - remove unsafe

I also found this point. Using Unsafe does not improve performance. It may require the implementation of instrinsic to be better than C2.

I also changed the code style of BufWriterImpl::writeUTF to make it more similar to DataOutputStream::writeUTF, and plan to use countGreaterThanZero in DataOutputStream#writeUTF later.

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2325422751

From dholmes at openjdk.org  Tue Sep  3 02:28:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Sep 2024 02:28:18 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
 <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>
Message-ID: <VcGVewtYspnLN09mP5vNhRjKpd_8cpcCndhyPmdaJCI=.af4869cc-b281-498f-9eda-009872be3a47@github.com>

On Mon, 2 Sep 2024 22:32:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744:
> 
>> 742:     int rslt = pthread_attr_init(&attr);
>> 743:     if (rslt != 0) return;
>> 744:     pthread_create(&thr, &attr, SplashScreenThread, (void *) splash);
> 
> You don't think it would be better to check the return code?

This code is devoid of pretty much all error handling and logging, but I agree that a simple fprintf on error would be useful.
Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741354811

From dholmes at openjdk.org  Tue Sep  3 03:00:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Sep 2024 03:00:56 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v3]
In-Reply-To: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
Message-ID: <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>

> This is the implementation of a new method added to the JNI specification.
> 
> From the CSR request:
> 
> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
> 
> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
> 
> Solution
> 
> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
> 
> ---
> 
> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
> 
> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
> 
> Testing:
>  - new test added
>  - tiers 1-3 sanity
> 
> Thanks

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

  The JNI version update was incompete

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20784/files
  - new: https://git.openjdk.org/jdk/pull/20784/files/73174e64..29cfa8ba

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

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

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

From dholmes at openjdk.org  Tue Sep  3 03:00:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Sep 2024 03:00:56 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <SYJj6vBnDnUNNJAXuWwWW1m_91b_eyMDf0oJp2aliYg=.1966ffb7-837b-447d-9c74-73e99d89a6e1@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
 <SYJj6vBnDnUNNJAXuWwWW1m_91b_eyMDf0oJp2aliYg=.1966ffb7-837b-447d-9c74-73e99d89a6e1@github.com>
Message-ID: <h2Yv5GRy4ZZ5oXv7G-lvpZbYPfAlJzLsaYtSl5VKhQ8=.f22db737-c5a3-4d8d-98f9-6454c596b391@github.com>

On Fri, 30 Aug 2024 20:45:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exclude test on 32-bit
>
> Overall it looks good to me, although I don't have experience adding a new JNI API (the dtrace probes were new to me), but it seems you are following what is already in place for other functions, and the testing looks good.

@plummercj  and @AlanBateman  could you please re-review as I was missing the main parts of the JNI version update! Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/20784#issuecomment-2325518928

From ihse at openjdk.org  Tue Sep  3 05:55:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Sep 2024 05:55:18 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <VcGVewtYspnLN09mP5vNhRjKpd_8cpcCndhyPmdaJCI=.af4869cc-b281-498f-9eda-009872be3a47@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
 <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>
 <VcGVewtYspnLN09mP5vNhRjKpd_8cpcCndhyPmdaJCI=.af4869cc-b281-498f-9eda-009872be3a47@github.com>
Message-ID: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com>

On Tue, 3 Sep 2024 02:25:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one?

Such a warning would be horrible to have enable. Then you would have to read the value of every function that thought it should return a value, even if it was just intended as some additional information that perhaps not everyone wanted to use. (And then you could not just store it into a variable and ignore it, since that would trigger the "unused variable" warning! ;-))

I know IntelliJ can provide warnings when ignoring the return value of a few select JDK methods that are often used incorrectly, but then they had to annotate these specially. I don't know if there is any similar kind of annotation for clang/gcc that can warn about ignoring return values that really, really shouldn't be ignored, but I'd guess not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741464573

From alanb at openjdk.org  Tue Sep  3 06:04:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 06:04:19 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v3]
In-Reply-To: <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>
Message-ID: <moAnb16oee_eGHtQPri_LQYDZau1TLNUu3czJq0yn7M=.deee844f-faea-49a0-873f-4afced8ddbf5@github.com>

On Tue, 3 Sep 2024 03:00:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of a new method added to the JNI specification.
>> 
>> From the CSR request:
>> 
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
>> 
>> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
>> 
>> Solution
>> 
>> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
>> 
>> ---
>> 
>> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
>> 
>> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
>> 
>> Testing:
>>  - new test added
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The JNI version update was incompete

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20784#pullrequestreview-2276469775

From dholmes at openjdk.org  Tue Sep  3 06:18:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Sep 2024 06:18:18 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
 <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>
 <VcGVewtYspnLN09mP5vNhRjKpd_8cpcCndhyPmdaJCI=.af4869cc-b281-498f-9eda-009872be3a47@github.com>
 <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com>
Message-ID: <dFTZkGHLLE_nFupik3FcJQczQZ2YayF0ZJh4FP6eln4=.e44ff0ba-df61-4f00-bea4-5d14f8c9f0be@github.com>

On Tue, 3 Sep 2024 05:52:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This code is devoid of pretty much all error handling and logging, but I agree that a simple fprintf on error would be useful.
>> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one?
>
>> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one?
> 
> Such a warning would be horrible to have enable. Then you would have to read the value of every function that thought it should return a value, even if it was just intended as some additional information that perhaps not everyone wanted to use. (And then you could not just store it into a variable and ignore it, since that would trigger the "unused variable" warning! ;-))
> 
> I know IntelliJ can provide warnings when ignoring the return value of a few select JDK methods that are often used incorrectly, but then they had to annotate these specially. I don't know if there is any similar kind of annotation for clang/gcc that can warn about ignoring return values that really, really shouldn't be ignored, but I'd guess not.

At one stage we started using the idiom:

(void) someFunc();

to tell the compiler to not warn about the unused result. IIRC that stopped working.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741484485

From dholmes at openjdk.org  Tue Sep  3 06:22:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Sep 2024 06:22:19 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v3]
In-Reply-To: <moAnb16oee_eGHtQPri_LQYDZau1TLNUu3czJq0yn7M=.deee844f-faea-49a0-873f-4afced8ddbf5@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>
 <moAnb16oee_eGHtQPri_LQYDZau1TLNUu3czJq0yn7M=.deee844f-faea-49a0-873f-4afced8ddbf5@github.com>
Message-ID: <Lc7cIU-GPWOOnWOkSNORkM1mHuSu6MyCoEO8e_BDT6E=.51b0df94-1cb5-42ee-9cdc-bfac69bd0d86@github.com>

On Tue, 3 Sep 2024 06:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The JNI version update was incompete
>
> Marked as reviewed by alanb (Reviewer).

Thanks @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/20784#issuecomment-2325689077

From jwaters at openjdk.org  Tue Sep  3 06:45:18 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 3 Sep 2024 06:45:18 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <dFTZkGHLLE_nFupik3FcJQczQZ2YayF0ZJh4FP6eln4=.e44ff0ba-df61-4f00-bea4-5d14f8c9f0be@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
 <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>
 <VcGVewtYspnLN09mP5vNhRjKpd_8cpcCndhyPmdaJCI=.af4869cc-b281-498f-9eda-009872be3a47@github.com>
 <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com>
 <dFTZkGHLLE_nFupik3FcJQczQZ2YayF0ZJh4FP6eln4=.e44ff0ba-df61-4f00-bea4-5d14f8c9f0be@github.com>
Message-ID: <bSqvR-vDWXT7BBQ9uOYRx-IQJrygn26skZv6uTue8CE=.24541305-9bc9-4c34-b752-a3e772dd0f6b@github.com>

On Tue, 3 Sep 2024 06:16:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one?
>> 
>> Such a warning would be horrible to have enable. Then you would have to read the value of every function that thought it should return a value, even if it was just intended as some additional information that perhaps not everyone wanted to use. (And then you could not just store it into a variable and ignore it, since that would trigger the "unused variable" warning! ;-))
>> 
>> I know IntelliJ can provide warnings when ignoring the return value of a few select JDK methods that are often used incorrectly, but then they had to annotate these specially. I don't know if there is any similar kind of annotation for clang/gcc that can warn about ignoring return values that really, really shouldn't be ignored, but I'd guess not.
>
> At one stage we started using the idiom:
> 
> (void) someFunc();
> 
> to tell the compiler to not warn about the unused result. IIRC that stopped working.

Not entirely sure about clang, but casting to void to silence warnings should still work for gcc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741510831

From mbaesken at openjdk.org  Tue Sep  3 07:13:19 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 07:13:19 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <bSqvR-vDWXT7BBQ9uOYRx-IQJrygn26skZv6uTue8CE=.24541305-9bc9-4c34-b752-a3e772dd0f6b@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
 <igLjFMZwZr-pJiYzZ5E9qFrMAOD66Lvzxi7SNHELyxA=.c4256988-3ae9-43eb-b599-c1a290c22bea@github.com>
 <VcGVewtYspnLN09mP5vNhRjKpd_8cpcCndhyPmdaJCI=.af4869cc-b281-498f-9eda-009872be3a47@github.com>
 <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com>
 <dFTZkGHLLE_nFupik3FcJQczQZ2YayF0ZJh4FP6eln4=.e44ff0ba-df61-4f00-bea4-5d14f8c9f0be@github.com>
 <bSqvR-vDWXT7BBQ9uOYRx-IQJrygn26skZv6uTue8CE=.24541305-9bc9-4c34-b752-a3e772dd0f6b@github.com>
Message-ID: <OSPlO9O2J_vuiGatV5SJQYKe4YSK5vfoN7NethO-OLA=.15f89aff-5889-47f7-a8ee-f9dc6ea03e55@github.com>

On Tue, 3 Sep 2024 06:42:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> At one stage we started using the idiom:
>> 
>> (void) someFunc();
>> 
>> to tell the compiler to not warn about the unused result. IIRC that stopped working.
>
> Not entirely sure about clang, but casting to void to silence warnings should still work for gcc

> You don't think it would be better to check the return code?

Hi , maybe we could check it ;  in HS code we mostly do  (but there we have UL).
But would be a separate PR I guess (splashscreen_sys.m on macOS has the same issue) .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741542559

From mbaesken at openjdk.org  Tue Sep  3 07:26:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 07:26:53 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v3]
In-Reply-To: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
Message-ID: <W2_wdkLnGuOLys4J-pWfraNhgDuq5UGo77XYE7Y9L44=.27712b5a-610e-4cd9-8b42-e47dcc29ab39@github.com>

> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>     char exePath[PATH_MAX];
>          ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>     int ret;
>         ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>     char fn[32];
>          ^
> 
> This seems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)

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

  TimeZone_md move platform stuff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20812/files
  - new: https://git.openjdk.org/jdk/pull/20812/files/082e6f60..e20948ca

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

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

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

From mbaesken at openjdk.org  Tue Sep  3 07:26:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 07:26:53 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v2]
In-Reply-To: <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <THmGrAyWicjbdHxgsFNcUQpzcN8mn4jom_fkjktQZ2M=.eff582ce-5f14-445c-98ff-6b8fb850e459@github.com>
Message-ID: <0_Av5QvMB9nUSbRIN-x2Z6OhkN__s0pzRSKw-8kEGLg=.7e4115e6-2f3a-4270-8fd7-f85ea8b2c137@github.com>

On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>>     char exePath[PATH_MAX];
>>          ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>>     int ret;
>>         ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>>     char fn[32];
>>          ^
>> 
>> This seems to be related to the recent make changes
>> 8339156: Use more fine-granular clang unused warnings
>> https://bugs.openjdk.org/browse/JDK-8339156
>> (we use clang too on AIX)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust indentation in X11Color.c

I would suggest creating a JBS issue and later PR for the pthread_create return code checking (both unix and macos).

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

PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2325785214

From duke at openjdk.org  Tue Sep  3 07:40:29 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 3 Sep 2024 07:40:29 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <jgrN6hGqHRGDUm8KHX_vpA-Ce9ayHtlTMsfyZyP_pp8=.1f057307-2ae1-4d62-9ddd-4c85b3cefba5@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <jgrN6hGqHRGDUm8KHX_vpA-Ce9ayHtlTMsfyZyP_pp8=.1f057307-2ae1-4d62-9ddd-4c85b3cefba5@github.com>
Message-ID: <CHRIr_xpEwxbARkwjotz31EbbjuyOofbhbDf3t1A3rg=.3830a77d-89b7-439e-bc25-78d46ad43199@github.com>

On Tue, 27 Aug 2024 17:09:18 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...
>
> Working on it

@galderz in the benchmark did you collected the mispredicts/branches?

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

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

From duke at openjdk.org  Tue Sep  3 08:06:27 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 3 Sep 2024 08:06:27 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <BRSoztZHBsmaftgGRen7zBAEF_aZ3NlBw7x42IjIr50=.217e8f69-1801-4f56-ace4-d1daa7768353@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <U1JQ2NfdXUV6mhhdmxDQQsYARgQjrEYqYsbJZwnH3ls=.e7b433f6-f0cb-4833-8724-b3afc76886df@github.com>
 <BRSoztZHBsmaftgGRen7zBAEF_aZ3NlBw7x42IjIr50=.217e8f69-1801-4f56-ace4-d1daa7768353@github.com>
Message-ID: <JU3AvdXBzVmKRH0q5u0a_ZbserEDvgat6oBjLjFQFdY=.fa12de04-675a-4210-82f0-bf5b8ed463ca@github.com>

On Mon, 2 Sep 2024 09:36:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This looks good. Again, the goal of this PR is not to squeeze every nanosecond out - but, rather, to achieve a performance model that is "sensible"

fully agree and yep - this looks pretty good already, well done @minborg ! thanks for it! I cannot wait to remove my ugly workaround of this for Netty :P

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

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2325857935

From pminborg at openjdk.org  Tue Sep  3 08:17:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 08:17:48 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
Message-ID: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>

This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.

Here is what it looks like for Windows x64:

![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)

Here is another chart for Linux a64:

![image](https://github.com/user-attachments/assets/87985561-3678-436c-b9e8-c7dd127347c3)

Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)

It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:


MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);


This could be added in a separate PR.

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

Commit messages:
 - Fix copyright years
 - Clean up
 - Increase threshhold to 64 bytes
 - Merge branch 'master' into copy-performance
 - Merge branch 'master' into mismatch-performance
 - Only handle disjunct mem copy
 - Add implementation
 - Improve benchmarks
 - Fix bugs
 - Add prototypes

Changes: https://git.openjdk.org/jdk/pull/20829/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338591
  Stats: 299 lines in 4 files changed: 286 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20829/head:pull/20829

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

From pminborg at openjdk.org  Tue Sep  3 08:22:02 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 08:22:02 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v11]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <FOIv7UQNFzFHsq1HW9uVJ4i1Z19SqkBqEO3PsLTaSYg=.808bd435-d8a7-46d7-8809-32ec7c227767@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/87e837b6-30e4-4299-a9a1-14776e575825)
> 
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

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

 - Merge branch 'master' into fill-performance
 - Restructure logic after comments
 - Revert copyright year
 - Move logic back to AMSI
 - Remove unused imports
 - Move logic to ScopedMemoryAccess for improved performance
 - Make minor updates after comments
 - Switch to bit checking instead of switch statement
 - Merge branch 'master' into fill-performance
 - Fix typo
 - ... and 4 more: https://git.openjdk.org/jdk/compare/726d0a24...d1641954

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/5c2ce6ad..d1641954

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

  Stats: 8765 lines in 272 files changed: 5557 ins; 1502 del; 1706 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

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

From pminborg at openjdk.org  Tue Sep  3 08:41:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 08:41:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <AMGRZZcYd6ybuKnxYlVXcR1k5xOjHAVYXMxexG4Jvu0=.9b790868-9864-4b43-9c92-ccb03addcb39@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
 <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>
 <7Bh_uU7pTTtY-bEIasYBKDLRshFPU_TTQSKlt37iFNU=.ce313a17-340d-4736-9a81-b56facf4ab7d@github.com>
 <AMGRZZcYd6ybuKnxYlVXcR1k5xOjHAVYXMxexG4Jvu0=.9b790868-9864-4b43-9c92-ccb03addcb39@github.com>
Message-ID: <bfh2jE8Q1uPK2nyVRZacI5277j7DbXrCCAqRvrQXCj8=.f064382d-df8d-4d91-a070-e39b30cdd09d@github.com>

On Mon, 2 Sep 2024 09:32:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> If I run:
>> 
>> 
>>     @Benchmark
>>     public long shift() {
>>         return ELEM_SIZE << 56 | ELEM_SIZE << 48 | ELEM_SIZE << 40 | ELEM_SIZE << 32 | ELEM_SIZE << 24 | ELEM_SIZE << 16 | ELEM_SIZE << 8 | ELEM_SIZE;
>>     }
>> 
>>     @Benchmark
>>     public long mul() {
>>         return ELEM_SIZE * 0xFFFF_FFFF_FFFFL;
>>     }
>> 
>> Then I get:
>> 
>> Benchmark       (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
>> TestFill.mul             31  avgt   30  0.586 ? 0.045  ns/op
>> TestFill.shift           31  avgt   30  0.938 ? 0.017  ns/op
>> 
>> On my M1 machine.
>
> I found similar small improvements to be had (I wrote about them offline) when replacing the bitwise-based tests (e.g. `foo & 4 != 0`) with a more explicit check for `remainingBytes >=4`. Seems like bitwise operations are not as optimized (or perhaps the assembly instructions for them is overall more convoluted - I haven't checked).

I've tried 


final long longValue = Byte.toUnsignedLong(value) * 0x0101010101010101L;


But it had the same performance as explicit bit shifting on M1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1741664877

From redestad at openjdk.org  Tue Sep  3 08:42:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 08:42:24 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v10]
In-Reply-To: <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
Message-ID: <7pqw4tL--BzE_G00Wbu-eLnnvzTKblJtnwVtO1_C7IQ=.786d9a46-57cf-4fcb-924c-5370834ba174@github.com>

On Tue, 3 Sep 2024 00:38:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - code style
>  - remove unsafe

Past experience with using intrinsics to replace similar counted loops shows that we can expect a 4-6x speed-up at scale, but only a very minor improvement for strings < 256 chars (branch, call and setup overheads eat up gains). See UTF-8 numbers here: https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html - where we replace an ASCII-checking loop with an intrinsic: https://github.com/openjdk/jdk/pull/2574/files#diff-e5a7e70ec8192692004da7744aa38f222c64697194fbdc5278a1945234bb57dcR231 

Since most strings in classfiles can be expected to be relatively short then a vectorized intrinsic might not be much of a win.

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2325931262

From pminborg at openjdk.org  Tue Sep  3 08:44:43 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 08:44:43 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v12]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <0AsYiLLCvdK2IyRLZHUqDjX_l7MSfjOzkIkdiltJ6wI=.299c1110-8296-4e81-a0f5-a985e51752e7@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/87e837b6-30e4-4299-a9a1-14776e575825)
> 
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

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

  Remove unintended file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/d1641954..f0ca9853

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=10-11

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

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

From duke at openjdk.org  Tue Sep  3 08:53:23 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 3 Sep 2024 08:53:23 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <bfh2jE8Q1uPK2nyVRZacI5277j7DbXrCCAqRvrQXCj8=.f064382d-df8d-4d91-a070-e39b30cdd09d@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
 <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>
 <7Bh_uU7pTTtY-bEIasYBKDLRshFPU_TTQSKlt37iFNU=.ce313a17-340d-4736-9a81-b56facf4ab7d@github.com>
 <AMGRZZcYd6ybuKnxYlVXcR1k5xOjHAVYXMxexG4Jvu0=.9b790868-9864-4b43-9c92-ccb03addcb39@github.com>
 <bfh2jE8Q1uPK2nyVRZacI5277j7DbXrCCAqRvrQXCj8=.f064382d-df8d-4d91-a070-e39b30cdd09d@github.com>
Message-ID: <701ixZdoVmW4ank46qLPUXz4feMQVmWjg4ZVKZIbUmk=.c5ecf381-7f4a-49ad-b36a-6a114de9c47c@github.com>

On Tue, 3 Sep 2024 08:39:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I found similar small improvements to be had (I wrote about them offline) when replacing the bitwise-based tests (e.g. `foo & 4 != 0`) with a more explicit check for `remainingBytes >=4`. Seems like bitwise operations are not as optimized (or perhaps the assembly instructions for them is overall more convoluted - I haven't checked).
>
> I've tried 
> 
> 
> final long longValue = Byte.toUnsignedLong(value) * 0x0101010101010101L;
> 
> 
> But it had the same performance as explicit bit shifting on M1.

@minborg the ` ELEM_SIZE` is a `Param` field right? Just to be 100% sure of it...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1741681612

From vklang at openjdk.org  Tue Sep  3 09:16:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Sep 2024 09:16:31 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
Message-ID: <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>

On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.
> 
> So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.
> 
> There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.
> 
> I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.
> 
> The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.

@DougLea @AlanBateman I'm currently trying to provoke the test to fail with this new implementation.

@DougLea @AlanBateman This seems to fix TestDisposerRace.java

Ready for review

Closing this PR and opening a new one, to see if that helps.

Gah, so it had nothing to do with the commit message. There was, for some reason, a tab in the JBS title which was copy-pasted in as the PR title.

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 286:

> 284:      */
> 285:     private final void reacquire(Node node, long arg) {
> 286:         for (long nanos = 1L;;) {

@AlanBateman @DougLea If we're concerned about SOE due to adding another stackframe by invoking reacquire we might consider ForceInline, but I was weary about doing so.

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 290:

> 288:                 acquire(node, arg, false, false, false, 0L);
> 289:                 break;
> 290:             } catch (Error | RuntimeException ex) {

@DougLea @AlanBateman The first question is if this set of exception are the way to go, or we should go with Throwable

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 294:

> 292:                 if (first) {
> 293:                     first = false;
> 294:                     // Log JFR event?

@DougLea @AlanBateman The second question is whether we should declare a JFR event for this use-case or not.

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 312:

> 310:             }
> 311:         }
> 312:     }

@DougLea @AlanBateman So I've added such that the first exception/error is rethrown after subsequent successful reacquisition. See above.

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

PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2292008244
PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2293131396
PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2296564889
PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2325963172
PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2326008569
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1719777654
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1718867228
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1718867694
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1731486424

From alanb at openjdk.org  Tue Sep  3 09:16:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 09:16:31 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
 <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
Message-ID: <tFTdkP9Uhs-zb9e2cMM-FyD_Yigm0vr-nQLvCYoKzqM=.ad68ce3c-aceb-4478-97f1-ae32eae03d0e@github.com>

On Fri, 16 Aug 2024 09:06:48 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> @DougLea @AlanBateman This seems to fix TestDisposerRace.java

That test runs with a small heap so I assume it's OOME. I can't help thinking we need to back off with a timed-Unsafe.park before retrying.

> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 294:
> 
>> 292:                 if (first) {
>> 293:                     first = false;
>> 294:                     // Log JFR event?
> 
> @DougLea @AlanBateman The second question is whether we should declare a JFR event for this use-case or not.

Creating/recording a JFR event would require executing Java code so might be problematic.  We could potentially a VM function that could be used for many cases, except SOE.

> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 312:
> 
>> 310:             }
>> 311:         }
>> 312:     }
> 
> @DougLea @AlanBateman So I've added such that the first exception/error is rethrown after subsequent successful reacquisition. See above.

Good.

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

PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2293198541
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1723165345
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1731493907

From vklang at openjdk.org  Tue Sep  3 09:16:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Sep 2024 09:16:32 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <tFTdkP9Uhs-zb9e2cMM-FyD_Yigm0vr-nQLvCYoKzqM=.ad68ce3c-aceb-4478-97f1-ae32eae03d0e@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
 <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
 <tFTdkP9Uhs-zb9e2cMM-FyD_Yigm0vr-nQLvCYoKzqM=.ad68ce3c-aceb-4478-97f1-ae32eae03d0e@github.com>
Message-ID: <7to8T1zYp_WfzVEvwIqVmF_TAwbLBUcrUzmfDrSvihA=.3db30523-4adb-44d7-a40c-7d336ca56867@github.com>

On Fri, 16 Aug 2024 09:51:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @DougLea @AlanBateman This seems to fix TestDisposerRace.java
>
>> @DougLea @AlanBateman This seems to fix TestDisposerRace.java
> 
> That test runs with a small heap so I assume it's OOME. I can't help thinking we need to back off with a timed-Unsafe.park before retrying.

@AlanBateman @DougLea

>That test runs with a small heap so I assume it's OOME. I can't help thinking we need to back off with a timed-Unsafe.park before retrying.

Yeah, I think that's fair enough. I have now added that using the same technique used for `acquireOnOOME`.

@AlanBateman This is now ready for review. Had to manually squash and force-push this PR as there was a tab in some commit message.

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

PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2293299636
PR Comment: https://git.openjdk.org/jdk/pull/20602#issuecomment-2318144917

From vklang at openjdk.org  Tue Sep  3 09:16:29 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Sep 2024 09:16:29 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
Message-ID: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>

My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.

So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.

There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.

I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.

The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.

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

Commit messages:
 - Harden reacquisition of AQS and AQLS Conditions

Changes: https://git.openjdk.org/jdk/pull/20602/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20602&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325397
  Stats: 129 lines in 3 files changed: 106 ins; 3 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20602.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20602/head:pull/20602

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

From vklang at openjdk.org  Tue Sep  3 09:16:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Sep 2024 09:16:32 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
 <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
Message-ID: <pDr3JFq8plWijlUGo57EDCYvmD9xG9Ple2badMTCzXU=.0e1bdb02-e3ee-4fdc-afd7-7c9d15e6508d@github.com>

On Thu, 15 Aug 2024 19:02:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.
>> 
>> So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.
>> 
>> There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.
>> 
>> I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.
>> 
>> The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.
>
> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 290:
> 
>> 288:                 acquire(node, arg, false, false, false, 0L);
>> 289:                 break;
>> 290:             } catch (Error | RuntimeException ex) {
> 
> @DougLea @AlanBateman The first question is if this set of exception are the way to go, or we should go with Throwable

One option is to record the first encountered exception instance, which can then be rethrown once acquire succeeds?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1718994076

From alanb at openjdk.org  Tue Sep  3 09:16:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 09:16:32 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <pDr3JFq8plWijlUGo57EDCYvmD9xG9Ple2badMTCzXU=.0e1bdb02-e3ee-4fdc-afd7-7c9d15e6508d@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
 <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
 <pDr3JFq8plWijlUGo57EDCYvmD9xG9Ple2badMTCzXU=.0e1bdb02-e3ee-4fdc-afd7-7c9d15e6508d@github.com>
Message-ID: <mPzDYa2Cl64jc6u570NZifvl-IRAE2Tz9zmh26RaVtA=.ecb26269-9556-42e6-9e7b-906778ee58f7@github.com>

On Thu, 15 Aug 2024 21:05:39 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 290:
>> 
>>> 288:                 acquire(node, arg, false, false, false, 0L);
>>> 289:                 break;
>>> 290:             } catch (Error | RuntimeException ex) {
>> 
>> @DougLea @AlanBateman The first question is if this set of exception are the way to go, or we should go with Throwable
>
> One option is to record the first encountered exception instance, which can then be rethrown once acquire succeeds?

Object.wait and Condition.await are unusual in that they must reacquire they continue, even if they throw. So might not be crazy for the cases where it does recover (I assume some cases will never recover and it will retry indefinitely).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1723182564

From vklang at openjdk.org  Tue Sep  3 09:16:33 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Sep 2024 09:16:33 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <mPzDYa2Cl64jc6u570NZifvl-IRAE2Tz9zmh26RaVtA=.ecb26269-9556-42e6-9e7b-906778ee58f7@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
 <994YQFmu9Zu7rW0CswP13-q3URZ0JC350aKi_FHqS3U=.ebe3ab8b-bf38-49af-866b-2450a8e2e4bd@github.com>
 <pDr3JFq8plWijlUGo57EDCYvmD9xG9Ple2badMTCzXU=.0e1bdb02-e3ee-4fdc-afd7-7c9d15e6508d@github.com>
 <mPzDYa2Cl64jc6u570NZifvl-IRAE2Tz9zmh26RaVtA=.ecb26269-9556-42e6-9e7b-906778ee58f7@github.com>
Message-ID: <so7ix8F2A_RkM0Ji642Z1Z5BlZEP5ICN8B7UlNZ1L3o=.f30d03ab-a465-484d-8abd-6771afb384d9@github.com>

On Tue, 20 Aug 2024 11:53:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> One option is to record the first encountered exception instance, which can then be rethrown once acquire succeeds?
>
> Object.wait and Condition.await are unusual in that they must reacquire they continue, even if they throw. So might not be crazy for the cases where it does recover (I assume some cases will never recover and it will retry indefinitely).

@DougLea What do you think about storing the initial exception and rethrowing it on an eventual retry success?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1723639098

From aturbanov at openjdk.org  Tue Sep  3 09:16:34 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 3 Sep 2024 09:16:34 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
Message-ID: <hJaTTxgMivUOfDk-37wWWEQ-QVjskBVXQNzl1poxKUM=.fbb7e5fb-b306-47b3-b200-5e5f38765719@github.com>

On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.
> 
> So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.
> 
> There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.
> 
> I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.
> 
> The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.

test/jdk/sun/java2d/Disposer/TestDisposerRace.java line 88:

> 86: 
> 87:     private static <T> T retryOnOOME(Supplier<T> allocator) {
> 88:         for(;;) {

nit
Suggestion:

        for (;;) {

test/jdk/sun/java2d/Disposer/TestDisposerRace.java line 100:

> 98: 
> 99:     private static <E extends Exception> void retryOnOOME(ThrowingRunnable<E> tr) throws E {
> 100:         for(;;) {

nit
Suggestion:

        for(;;) {

test/jdk/sun/java2d/Disposer/TestDisposerRace.java line 117:

> 115:         MyDisposerRecord disposerRecord = retryOnOOME(MyDisposerRecord::new);
> 116: 
> 117:         while(count > 0) {

Suggestion:

        while (count > 0) {

test/jdk/sun/java2d/Disposer/TestDisposerRace.java line 117:

> 115:         MyDisposerRecord disposerRecord = retryOnOOME(MyDisposerRecord::new);
> 116: 
> 117:         while(count > 0) {

nit
Suggestion:

        while (count > 0) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1736738246
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1736738799
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1732793046
PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1736739470

From redestad at openjdk.org  Tue Sep  3 09:19:26 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 09:19:26 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v10]
In-Reply-To: <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
Message-ID: <rgxU1YQPYkMeQNovXpSHXu-JrartxkkA9KXcTlZg_yo=.ba8995a6-4dea-4cf4-8717-f07d6137ea85@github.com>

On Tue, 3 Sep 2024 00:38:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - code style
>  - remove unsafe

I think this is looking much better now, thanks! There's some polish I'd like to see made, though.

src/java.base/share/classes/java/lang/System.java line 2597:

> 2595:             }
> 2596: 
> 2597:             public byte stringCoder(String s) {

I think it'd be better to do `boolean isLatin1(String s)` here. It's still somewhat leaky, but keeps things a bit more high-level, containing more of the low-level details. Seems all uses basically just checks `coder == 0` anyhow.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 182:

> 180:         byte[] elems = this.elems;
> 181: 
> 182:         str.getBytes(0, countGreaterThanZero, elems, offset);

Might be beneficial to non-latin1 case to move this up into the latin1 block.

Could you verify the 256 limit is useful? Add a couple of cases to the micro with much longer latin1 strings; both ASCII and with non-ASCII at the end. Would be nice if we can keep this simple and the "too long" check feels a bit premature.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 201:

> 199:         }
> 200:         int utflen = offset - start - 2;
> 201:         if (utflen > 65535) {

Previously we'd count bytes and throw before writing to the byte array. Perhaps this is still preferable, even if it comes at a cost.

test/micro/org/openjdk/bench/java/lang/classfile/Utf8EntryWriteTo.java line 76:

> 74:         byte[] bytes = HexFormat.of().parseHex(
> 75:                 switch (charType) {
> 76:                     case "ascii"        -> "78";

Might be good to randomize these inputs a bit.

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2276820291
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741719346
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741713216
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741717901
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741688429

From redestad at openjdk.org  Tue Sep  3 09:26:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 09:26:24 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v10]
In-Reply-To: <rgxU1YQPYkMeQNovXpSHXu-JrartxkkA9KXcTlZg_yo=.ba8995a6-4dea-4cf4-8717-f07d6137ea85@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
 <rgxU1YQPYkMeQNovXpSHXu-JrartxkkA9KXcTlZg_yo=.ba8995a6-4dea-4cf4-8717-f07d6137ea85@github.com>
Message-ID: <5j_2i5nzBHnpNaXQCttGaCmkVqVk6CR4KPz4MWMviaA=.279161dd-59be-4d10-ba14-cb28397997e3@github.com>

On Tue, 3 Sep 2024 08:54:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - code style
>>  - remove unsafe
>
> test/micro/org/openjdk/bench/java/lang/classfile/Utf8EntryWriteTo.java line 76:
> 
>> 74:         byte[] bytes = HexFormat.of().parseHex(
>> 75:                 switch (charType) {
>> 76:                     case "ascii"        -> "78";
> 
> Might be good to randomize these inputs a bit.

I also note that all Strings are the same length. With vectorization on the table we'd want to test a healthy mix of strings of various lengths. @liach also suggested somewhere that strings which have a leading ASCII substring then a non-ASCII somewhere in the middle or near the end had a regression in an earlier iteration. It would be good to have a micro test for such strings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741732133

From mdoerr at openjdk.org  Tue Sep  3 09:33:20 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Sep 2024 09:33:20 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v3]
In-Reply-To: <W2_wdkLnGuOLys4J-pWfraNhgDuq5UGo77XYE7Y9L44=.27712b5a-610e-4cd9-8b42-e47dcc29ab39@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <W2_wdkLnGuOLys4J-pWfraNhgDuq5UGo77XYE7Y9L44=.27712b5a-610e-4cd9-8b42-e47dcc29ab39@github.com>
Message-ID: <AezIGuWfTxX1kQx0v8S9gmLKc4f2welK6i1YHWu2umo=.5a919714-3876-4e81-b300-27f66f38cd0d@github.com>

On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>>     char exePath[PATH_MAX];
>>          ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>>     int ret;
>>         ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>>     char fn[32];
>>          ^
>> 
>> This seems to be related to the recent make changes
>> 8339156: Use more fine-granular clang unused warnings
>> https://bugs.openjdk.org/browse/JDK-8339156
>> (we use clang too on AIX)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TimeZone_md move platform stuff

Thanks for the update! I also think that adding result checks is better in a separate RFE. This build fix is good to go IMHO.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2276906529

From swen at openjdk.org  Tue Sep  3 09:56:52 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 09:56:52 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v11]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <9g4kgITSJs8icvwpIDcbJE1ZXZGGvRQOxLXARF1adpU=.536d6275-c37b-420f-95ce-4cb62e24581f@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

 - optimize writeUTF
 - stringCoder -> isLatin1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/10cc1535..ce6c71e2

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

  Stats: 40 lines in 3 files changed: 16 ins; 14 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From swen at openjdk.org  Tue Sep  3 10:17:39 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 10:17:39 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v12]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <NcvWAymqLOxJMa20guIlwvvCF2rKdoe-lQ7nQOA5yvs=.817db86e-e75e-474b-b6d3-3800b957ec5b@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

 - improve benchmark, from @liach & @cl4es
 - remove 256

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/ce6c71e2..77df66f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=10-11

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

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

From swen at openjdk.org  Tue Sep  3 10:17:40 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 10:17:40 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v10]
In-Reply-To: <rgxU1YQPYkMeQNovXpSHXu-JrartxkkA9KXcTlZg_yo=.ba8995a6-4dea-4cf4-8717-f07d6137ea85@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <iaSu5Q8E_YGZvd-YZZlQN-Sv6N9eVyDZWk1pQm-OAFw=.e0adb724-5073-4ab2-9888-1acf5887f458@github.com>
 <rgxU1YQPYkMeQNovXpSHXu-JrartxkkA9KXcTlZg_yo=.ba8995a6-4dea-4cf4-8717-f07d6137ea85@github.com>
Message-ID: <20oA_rPY6WIQ0jen15w3wyd4cMcHbSlTsvGC2gV4nnU=.788d87a7-e2d5-45d8-be02-c34bb073db4a@github.com>

On Tue, 3 Sep 2024 09:11:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - code style
>>  - remove unsafe
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 182:
> 
>> 180:         byte[] elems = this.elems;
>> 181: 
>> 182:         str.getBytes(0, countGreaterThanZero, elems, offset);
> 
> Might be beneficial to non-latin1 case to move this up into the latin1 block.
> 
> Could you verify the 256 limit is useful? Add a couple of cases to the micro with much longer latin1 strings; both ASCII and with non-ASCII at the end. Would be nice if we can keep this simple and the "too long" check feels a bit premature.

I verified locally that the 256 limit didn't help, so I removed it. In fact, some MethodTypeDesc may exceed 256.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741803150

From mcimadamore at openjdk.org  Tue Sep  3 10:28:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Sep 2024 10:28:25 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v12]
In-Reply-To: <0AsYiLLCvdK2IyRLZHUqDjX_l7MSfjOzkIkdiltJ6wI=.299c1110-8296-4e81-a0f5-a985e51752e7@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <0AsYiLLCvdK2IyRLZHUqDjX_l7MSfjOzkIkdiltJ6wI=.299c1110-8296-4e81-a0f5-a985e51752e7@github.com>
Message-ID: <hltp40QV8ig-LT7yd7jbc5QCc69pT4jNCFpyLfsReW0=.5cfc10a9-f51f-4e39-9e8d-6e72d3e462f2@github.com>

On Tue, 3 Sep 2024 08:44:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/87e837b6-30e4-4299-a9a1-14776e575825)
>> 
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unintended file

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2277019952

From pminborg at openjdk.org  Tue Sep  3 10:28:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 10:28:26 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <701ixZdoVmW4ank46qLPUXz4feMQVmWjg4ZVKZIbUmk=.c5ecf381-7f4a-49ad-b36a-6a114de9c47c@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
 <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>
 <7Bh_uU7pTTtY-bEIasYBKDLRshFPU_TTQSKlt37iFNU=.ce313a17-340d-4736-9a81-b56facf4ab7d@github.com>
 <AMGRZZcYd6ybuKnxYlVXcR1k5xOjHAVYXMxexG4Jvu0=.9b790868-9864-4b43-9c92-ccb03addcb39@github.com>
 <bfh2jE8Q1uPK2nyVRZacI5277j7DbXrCCAqRvrQXCj8=.f064382d-df8d-4d91-a070-e39b30cdd09d@github.com>
 <701ixZdoVmW4ank46qLPUXz4feMQVmWjg4ZVKZIbUmk=.c5ecf381-7f4a-49ad-b36a-6a114de9c47c@github.com>
Message-ID: <pnPUrre3a9XkWPqJpSz-Lr-E_O5I1VJVucvKIDwl7b4=.891dbafc-4af6-40c9-b9aa-18c10c3f1a55@github.com>

On Tue, 3 Sep 2024 08:49:58 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> I've tried 
>> 
>> 
>> final long longValue = Byte.toUnsignedLong(value) * 0x0101010101010101L;
>> 
>> 
>> But it had the same performance as explicit bit shifting on M1.
>
> @minborg the ` ELEM_SIZE` is a `Param` field right? Just to be 100% sure of it...

yes it is. But I think the reason we are not seeing any difference is that in the fill benchmarks, we are always using a value of zero. We should keep this trick in mind for later...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1741814268

From pminborg at openjdk.org  Tue Sep  3 10:28:27 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 10:28:27 GMT
Subject: Integrated: 8338967: Improve performance for MemorySegment::fill
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <JBWK8yVxamwWiZEs__zuClx9Ar0jutwcd8dhPSneVjM=.599e67a5-c954-42b6-ab4b-3a1f19b4892f@github.com>

On Mon, 26 Aug 2024 11:47:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/87e837b6-30e4-4299-a9a1-14776e575825)
> 
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

This pull request has now been integrated.

Changeset: 7a418fc0
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a418fc07464fe359a0b45b6d797c65c573770cb
Stats:     277 lines in 3 files changed: 274 ins; 0 del; 3 mod

8338967: Improve performance for MemorySegment::fill

Reviewed-by: mcimadamore, psandoz

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

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

From alanb at openjdk.org  Tue Sep  3 10:29:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 10:29:19 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
Message-ID: <UnBZZQQ_G_av-q9ByPHtajTQlKlXRlwAvOu4ExuITm4=.b28136d4-746d-49e4-9b1f-b7efaae2dfee@github.com>

On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.
> 
> So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.
> 
> There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.
> 
> I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.
> 
> The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20602#pullrequestreview-2277029934

From swen at openjdk.org  Tue Sep  3 11:27:53 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 11:27:53 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v13]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <3cx4r9jNWFq4yWk3PqMzdgQ0DXAis1LHIBIrfaS3qcg=.cd42d4a1-b3e0-4630-9f21-ab5d95c8b930@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  fix testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/77df66f4..c37dea67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=11-12

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

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

From mcimadamore at openjdk.org  Tue Sep  3 11:35:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Sep 2024 11:35:20 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <1tf78Rq_sNUNnhSnMbYGFECd46w9jFaUpekOpgtxMqA=.8e0b0bb8-4aba-4681-9b3e-ec00144002b5@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

Marked as reviewed by mcimadamore (Reviewer).

The changes look good, I've tested on my machine and also got a nice bump for small size (which is the goal here).

Thanks also for updating the tests to make sure the new code is covered.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 625:

> 623:         if (size <= 0) {
> 624:             // Do nothing
> 625:         } else if (size < COPY_NATIVE_THRESHOLD && !src.overlaps(dst)) {

This is basically a conservative test - correct? E.g. we might end up cosidering two segments as overlapping even when they are not (because of offsets) - but that's ok, I actually think it's a good pragmatic solution.

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

PR Review: https://git.openjdk.org/jdk/pull/20829#pullrequestreview-2277168561
PR Comment: https://git.openjdk.org/jdk/pull/20829#issuecomment-2326288310
PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1741898334

From duke at openjdk.org  Tue Sep  3 11:50:19 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Tue, 3 Sep 2024 11:50:19 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <kUX5PWUEXHw2mfVikVY9YKc3aNzCFtRIRd8xar2qECw=.3004294d-3abd-47e7-bc97-cfb65ab09772@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

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

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

PR Review: https://git.openjdk.org/jdk/pull/20829#pullrequestreview-2277198109

From duke at openjdk.org  Tue Sep  3 11:56:19 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 3 Sep 2024 11:56:19 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <RKgJNkD0ltxgiJkiGuEVTibPU9t2Cp2coVVK45oTfnI=.f04b37fa-16ff-4633-b66e-2c9938687fc3@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 642:

> 640:             // 0...0X00
> 641:             if (remaining >= 4) {
> 642:                 final int v = SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(),src.unsafeGetOffset() + srcOffset + offset);

src.sessionImpl() worth being hoisted out once? It's a minor thing eh -same for `dst` and base/offsets

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1741922136

From duke at openjdk.org  Tue Sep  3 11:57:21 2024
From: duke at openjdk.org (duke)
Date: Tue, 3 Sep 2024 11:57:21 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions [v2]
In-Reply-To: <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
 <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>
Message-ID: <q7AbhhuNbjZLgOnijeHpCDFG4pG9Lg5GcQMUEucJ-l0=.0da31d6b-7a45-4020-997f-e28e69522d39@github.com>

On Mon, 2 Sep 2024 14:50:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

@wenshao 
Your change (at version 58a15b38e7ab8a0b7fb64e76d03dce516f9ff04a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20739#issuecomment-2326333130

From mbaesken at openjdk.org  Tue Sep  3 12:05:25 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 12:05:25 GMT
Subject: Integrated: 8339364: AIX build fails: various unused variable and
 function warnings
In-Reply-To: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
Message-ID: <snfNlmZMwM13FFG9TVc6NM2cOeeq4tWGWNeQNnZzWGk=.0905e1c1-41b4-4e97-8054-bc421017369b@github.com>

On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>     char exePath[PATH_MAX];
>          ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>     int ret;
>         ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>     char fn[32];
>          ^
> 
> This seems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)

This pull request has now been integrated.

Changeset: 8ea6adc6
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ea6adc623ca2183046d794eba806065deea916e
Stats:     65 lines in 14 files changed: 9 ins; 40 del; 16 mod

8339364: AIX build fails: various unused variable and function warnings

Reviewed-by: mdoerr, clanger, jwaters

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

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

From redestad at openjdk.org  Tue Sep  3 12:07:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 12:07:27 GMT
Subject: RFR: 8339401: Optimize ClassFile load and store instructions [v2]
In-Reply-To: <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
 <3XY7MU4OTOmfh_aFThjC3sV0RT15q0hFCZ8ZMqmIfgw=.8bd61fff-a9c7-4c13-8b99-c8ebc52e410b@github.com>
Message-ID: <At-xrG4xh71k8gI0g-Boocd-qOo_o65S1Q58Qr1OHgc=.ae417d6c-2439-402a-9086-14833c0e760e@github.com>

On Mon, 2 Sep 2024 14:50:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20739#pullrequestreview-2277230070

From swen at openjdk.org  Tue Sep  3 12:07:28 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 12:07:28 GMT
Subject: Integrated: 8339401: Optimize ClassFile load and store instructions
In-Reply-To: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
References: <jtkke5NMpaDgrma4y9nEnMXf5K2e00tbaGurPe3hjiY=.5ec56512-0903-4167-9312-a4598cb3600f@github.com>
Message-ID: <KElr1SwkLqN9CDvH9USpjvSf-jtrB2HJFCrgnivdtwQ=.2b67e05b-f10f-4bfe-8ecb-6960a6952d1b@github.com>

On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size greater than 325, break it into multiple small methods and call them directly in DirectCodeBuilder

This pull request has now been integrated.

Changeset: b94c3deb
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b94c3debf5083dbf5bc21ed7794c1656743ab48e
Stats:     178 lines in 2 files changed: 106 ins; 0 del; 72 mod

8339401: Optimize ClassFile load and store instructions

Reviewed-by: liach, redestad

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

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

From mbaesken at openjdk.org  Tue Sep  3 12:09:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 12:09:23 GMT
Subject: RFR: 8339364: AIX build fails: various unused variable and
 function warnings [v3]
In-Reply-To: <W2_wdkLnGuOLys4J-pWfraNhgDuq5UGo77XYE7Y9L44=.27712b5a-610e-4cd9-8b42-e47dcc29ab39@github.com>
References: <ACR4Q4agqSEvIno3SmkZDKkw5Z3lorh5FcWLV3TN638=.85d1504f-7757-4b1c-bde3-7056dcabadcd@github.com>
 <W2_wdkLnGuOLys4J-pWfraNhgDuq5UGo77XYE7Y9L44=.27712b5a-610e-4cd9-8b42-e47dcc29ab39@github.com>
Message-ID: <JdrswSokMMG7XIc6kSt7gixPNaLGTqglHhO_xk95CYc=.448a9d48-f937-4474-838f-5c72a8ca25d6@github.com>

On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We get a couple of warnings as errors on AIX because of unused variables or functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable]
>>     char exePath[PATH_MAX];
>>          ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable]
>>     int ret;
>>         ^
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable]
>>     char fn[32];
>>          ^
>> 
>> This seems to be related to the recent make changes
>> 8339156: Use more fine-granular clang unused warnings
>> https://bugs.openjdk.org/browse/JDK-8339156
>> (we use clang too on AIX)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TimeZone_md move platform stuff

I created https://bugs.openjdk.org/browse/JDK-8339475 for the pthread_create return code checking.

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

PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2326356942

From redestad at openjdk.org  Tue Sep  3 12:12:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 12:12:20 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v2]
In-Reply-To: <sRGOv3RPJ1qk5XBxS0cpTvaNZILptYxP_wrG4zmlyqs=.aa05bdab-a80a-4371-95c7-2dba8c15c415@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <sRGOv3RPJ1qk5XBxS0cpTvaNZILptYxP_wrG4zmlyqs=.aa05bdab-a80a-4371-95c7-2dba8c15c415@github.com>
Message-ID: <s8i1we3IbZhfk4K0VWJqtBvC9C7Z3ayQML0aBDxhGi4=.c4e50e66-4a70-41bd-b811-6b92b19072fa@github.com>

On Fri, 30 Aug 2024 05:13:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions from @cl4es

What I noticed is that in all but one place where we call `slotSize` we're dealing parameters which can't be void. So specializing and having a `paramSlotSize(ClassDesc desc) { return isDoubleSlot(desc) ? 2 : 1; }` would perhaps be better.

As always it's good to annotate performance enhancements like these with some microbenchmark data - if not else to indicate how you've evaluated the gain.

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

PR Comment: https://git.openjdk.org/jdk/pull/20747#issuecomment-2326361775

From epeter at openjdk.org  Tue Sep  3 12:15:31 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 3 Sep 2024 12:15:31 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
Message-ID: <7bghGF2-qbhP1hJA2ljtdA3xSUSqiV0RLaOYm4AcZSQ=.eb3e36b2-5461-4755-ae71-2de89660649f@github.com>

On Thu, 29 Aug 2024 05:42:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding descriptive comments

Ok, I left a few more comments.

Generally, this looks like a nice feature, thanks for implementing it @jatin-bhateja ! ? 

A few issues with code style (camelCase vs snake_case).
I'm also wondering about good naming. Why did we/you chose "select" for this? Why not "shuffle"? Does "select" not often get used as synonym of "blend", which has different semantics?

Also: I'm a little worried about the semantics change of the RearrangeNode that you did with the changes in `RearrangeNode::Ideal`. It looks a little "hacky", especially in conjunction with the `vector_indexes_needs_massaging` method. Can you give a clear definition of the semantics of `RearrangeNode` and `vector_indexes_needs_massaging`, please?

I also added some control questions for testing.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6446:

> 6444: }
> 6445: 
> 6446: void C2_MacroAssembler::select_from_two_vector_evex(BasicType elem_bt, XMMRegister dst, XMMRegister src1,

I also wonder if you could use the plural in these cases? You are selecting from two vectors, with the plural "s". Of course it is a bit annoying if you would have to name the IR node `SelectFromTwoVectors`, because we usually name the vector nodes `...Vector`, without the plural "s".

src/hotspot/share/opto/library_call.cpp line 749:

> 747:     return inline_vector_compress_expand();
> 748:   case vmIntrinsics::_VectorSelectFromTwoVectorOp:
> 749:     return inline_vector_select_from_two_vectors();

Interesting, here you use the correct plural "vectors".

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 544:

> 542:         byte[] vpayload1 = ((ByteVector)v1).vec();
> 543:         byte[] vpayload2 = ((ByteVector)v2).vec();
> 544:         byte[] vpayload3 = ((ByteVector)v3).vec();

Is there a reason you are not using more descriptive names here instead of `vpayload1`?
I also wonder if the `selectFromHelper` should not be named more specifically: `selectFromTwoVector(s)Helper`?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2595:

> 2593:     @ForceInline
> 2594:     final ByteVector selectFromTemplate(ByteVector v1, ByteVector v2) {
> 2595:         int twovectorlen = length() * 2;

`twovectorlen` -> `twoVectorLen`
I think in Java we are supposed to use camelCase

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 2770:

> 2768: 
> 2769:     /**
> 2770:      * Rearranges the lane elements of two vectors, selecting lanes

I have a bit of a name concern here. Why are we calling it "select" and not "rearrange"? Because for a single "from" vector we also call it "rearrange", right? Is "select" not often synonymous to "blend", which works also with two "from" vectors, but with a mask and not indexing for "selection/rearranging"?

test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 324:

> 322:                     boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 323:                     int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 324:                     Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]));

I thought general Java style is camelCase? Is that not followed in the VectorAPI code?

test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 1048:

> 1046:         return SHORT_GENERATOR_SELECT_FROM_TRIPLES.stream().map(List::toArray).
> 1047:                 toArray(Object[][]::new);
> 1048:     }

Just a control question: does this also occasionally generate examples with out-of-bounds indices? Negative out of bounds and positive out of bounds?

test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 5812:

> 5810:                 ShortVector bv = ShortVector.fromArray(SPECIES, b, i);
> 5811:                 ShortVector idxv = ShortVector.fromArray(SPECIES, idx, i);
> 5812:                 idxv.selectFrom(av, bv).intoArray(r, i);

Would this test catch a bug where the backend would generate vectors that are too long or too short?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2276944129
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741766060
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741773766
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741914524
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741911809
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741919025
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741920940
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741947885
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741949290

From epeter at openjdk.org  Tue Sep  3 12:15:32 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 3 Sep 2024 12:15:32 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
Message-ID: <XucrjYVZXMoCDdsk7Iy0xmkeBDN3EmETGgg3kW1j-VI=.25341282-5249-4ee0-8a02-dca19db23e49@github.com>

On Fri, 30 Aug 2024 14:02:46 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding descriptive comments
>
> src/hotspot/cpu/x86/x86.ad line 10490:
> 
>> 10488: 
>> 10489: 
>> 10490: instruct selectFromTwoVec_evex(vec dst, vec src1, vec src2)
> 
> You could rename `dst` -> `mask_and_dst`. That would maybe help the reader to more quickly know that it is an input-mask and output-dst.

Also, for consistency, I would write out the name `selectFromTwoVector(s)_evex`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1741772354

From swen at openjdk.org  Tue Sep  3 12:20:33 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 12:20:33 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v2]
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <H9y64nD852LZ9Wegk-nDM7BCSvD2xfjYYfNqA2wvaOI=.fee19dc8-5d9e-46b1-9783-131bb2773c59@github.com>

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

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

  Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20780/files
  - new: https://git.openjdk.org/jdk/pull/20780/files/8843b7c5..3d6868f7

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

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

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

From redestad at openjdk.org  Tue Sep  3 12:20:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 12:20:34 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v2]
In-Reply-To: <H9y64nD852LZ9Wegk-nDM7BCSvD2xfjYYfNqA2wvaOI=.fee19dc8-5d9e-46b1-9783-131bb2773c59@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <H9y64nD852LZ9Wegk-nDM7BCSvD2xfjYYfNqA2wvaOI=.fee19dc8-5d9e-46b1-9783-131bb2773c59@github.com>
Message-ID: <-bwRaN1rJNsxIOHf2B5SAX9euwlEYMu60cz6MRvR2sw=.bd2a11eb-b509-40f2-8183-050cb55e952f@github.com>

On Tue, 3 Sep 2024 12:17:45 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

Looks ok, a couple of nits.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 197:

> 195:             grow(nextOffset);
> 196:         }
> 197:         this.offset = nextOffset;

Let's not duplicate code to get rid of a simple addition
Suggestion:

        reserveSpace(skipSize);
        this.offset += skipSize;

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 285:

> 283:                                     b.writeBytes(bytecode.array(), 0, bytecode.limit());
> 284:                                     b.skip(2);//exception handlers
> 285:                                     b.skip(2);//attributes

Suggestion:

                                    b.skip(4); //exception handlers (2) + attributes (2)

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

PR Review: https://git.openjdk.org/jdk/pull/20780#pullrequestreview-2277250897
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1741955557
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1741948921

From swen at openjdk.org  Tue Sep  3 12:23:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 12:23:50 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v3]
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <JoSeYIgfRBiJz-2lGVh7VlwA04bK-KDH2PS0IgLOxbU=.4247847f-c292-458f-8bba-6b4b406a25a9@github.com>

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

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

  Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20780/files
  - new: https://git.openjdk.org/jdk/pull/20780/files/3d6868f7..d7227a9c

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

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

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

From redestad at openjdk.org  Tue Sep  3 12:27:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 12:27:25 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v13]
In-Reply-To: <3cx4r9jNWFq4yWk3PqMzdgQ0DXAis1LHIBIrfaS3qcg=.cd42d4a1-b3e0-4630-9f21-ab5d95c8b930@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <3cx4r9jNWFq4yWk3PqMzdgQ0DXAis1LHIBIrfaS3qcg=.cd42d4a1-b3e0-4630-9f21-ab5d95c8b930@github.com>
Message-ID: <CVH5SeCRFx7k11B35hSUTJr3ZCv7LVY-T-_EwSMKYtQ=.7cb06288-7a7a-487a-ae45-2016734222f1@github.com>

On Tue, 3 Sep 2024 11:27:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix testcase

src/java.base/share/classes/java/lang/System.java line 2598:

> 2596: 
> 2597:             public boolean isLatin1(String s) {
> 2598:                 return s.coder() == String.LATIN1;

I recall JEP 254 authors made a point that the test for `COMPACT_STRINGS` in `String#isLatin1()` helps JIT do better dead code elimination when running with `-XX:-CompactStrings`. Also: no logic in access bridges. :)  
Suggestion:

                return s.isLatin1();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741969049

From redestad at openjdk.org  Tue Sep  3 12:28:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 12:28:19 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v3]
In-Reply-To: <JoSeYIgfRBiJz-2lGVh7VlwA04bK-KDH2PS0IgLOxbU=.4247847f-c292-458f-8bba-6b4b406a25a9@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <JoSeYIgfRBiJz-2lGVh7VlwA04bK-KDH2PS0IgLOxbU=.4247847f-c292-458f-8bba-6b4b406a25a9@github.com>
Message-ID: <occ8455l4LN9t5jF4KmP6ZH8g9KM32qhU2azvifWwHk=.fd3a70d7-fd1b-400e-9e51-b9cae6b101e4@github.com>

On Tue, 3 Sep 2024 12:23:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20780#pullrequestreview-2277286119

From duke at openjdk.org  Tue Sep  3 12:36:24 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 3 Sep 2024 12:36:24 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <OXqxpbJx10Cy0Yr81_AWljHm8b-_bPQJM4Nf57KIn9s=.f276b3a6-6066-497a-80de-bd8e686fa543@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

I would suggest this additional benchmark as well


import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.CompilerControl;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.infra.BenchmarkParams;

import java.lang.foreign.Arena;
import java.lang.foreign.MemorySegment;
import java.nio.ByteBuffer;
import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(value = 3)
public class PolluteCopyTest {

    @Param({"0", "1", "2", "3", "4", "5", "6", "7", "8",
            "9", "10", "11", "12", "13", "14", "15", "16",
            "17", "18", "19", "20", "21", "22", "23", "24",
            "25", "26", "27", "28", "29", "30", "31", "32",
            "33", "36", "40", "44", "48", "52", "56", "60", "63", "64", "128"})
    public int ELEM_SIZE;

    MemorySegment heapSrcSegment;
    MemorySegment heapDstSegment;
    MemorySegment nativeSrcSegment;
    MemorySegment nativeDstSegment;

    @Param({"false", "true"})
    public boolean polluteCopy;

    @Setup
    public void setup(BenchmarkParams params) {
        byte[] srcArray = new byte[ELEM_SIZE];
        byte[] dstArray = new byte[ELEM_SIZE];
        heapSrcSegment = MemorySegment.ofArray(srcArray);
        heapDstSegment = MemorySegment.ofArray(dstArray);
        nativeSrcSegment = Arena.ofAuto().allocate(ELEM_SIZE);
        nativeDstSegment = Arena.ofAuto().allocate(ELEM_SIZE);
        if (polluteCopy) {
            if (params.getBenchmark().contains("not_inlined")) {
                for (int i = 0; i < 15_000; i++) {
                    heap_segment_copy5Arg_not_inlined();
                    native_segment_copy5Arg_not_inlined();
                }
            } else {
                for (int i = 0; i < 15_000; i++) {
                    MemorySegment.copy(heapSrcSegment, 0, heapDstSegment, 0, ELEM_SIZE);
                    MemorySegment.copy(nativeSrcSegment, 0, nativeDstSegment, 0, ELEM_SIZE);
                    MemorySegment.copy(heapSrcSegment, 0, nativeDstSegment, 0, ELEM_SIZE);
                    MemorySegment.copy(nativeSrcSegment, 0, heapDstSegment, 0, ELEM_SIZE);
                }
            }
        }
    }

    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public void heap_segment_copy5Arg_not_inlined() {
        MemorySegment.copy(heapSrcSegment, 0, heapDstSegment, 0, ELEM_SIZE);
    }

    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public void native_segment_copy5Arg_not_inlined() {
        MemorySegment.copy(nativeSrcSegment, 0, nativeDstSegment, 0, ELEM_SIZE);
    }

    @Benchmark
    public void heap_segment_copy5Arg() {
        MemorySegment.copy(heapSrcSegment, 0, heapDstSegment, 0, ELEM_SIZE);
    }

    @Benchmark
    public void native_segment_copy5Arg() {
        MemorySegment.copy(nativeSrcSegment, 0, nativeDstSegment, 0, ELEM_SIZE);
    }

}

which is not super stable (we can disable background compilation and enable type profiling - to make sure that we are doing things right by the end of `Setup` - or warmup at least)

It pollutes the type profile of existing copy methods in different ways - but while compiled, it will eventually depends on how types are handled.
There's no branch mispredict here, but a "what happen if we move the ops to java and java is type "poisoned/pollute"?" - because is what could happen in the real world (a mix of heap/off-heap segment types) and we want to capture what this PR get in such case as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20829#issuecomment-2326404582

From pminborg at openjdk.org  Tue Sep  3 12:36:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 3 Sep 2024 12:36:25 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1tf78Rq_sNUNnhSnMbYGFECd46w9jFaUpekOpgtxMqA=.8e0b0bb8-4aba-4681-9b3e-ec00144002b5@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <1tf78Rq_sNUNnhSnMbYGFECd46w9jFaUpekOpgtxMqA=.8e0b0bb8-4aba-4681-9b3e-ec00144002b5@github.com>
Message-ID: <XaUj70P5KzY4IGPLjDGbpifCMN4fIzirMlRWRCYElrQ=.7b000153-c2a2-4f31-96b3-fb2772d2bf5c@github.com>

On Tue, 3 Sep 2024 11:32:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
>> 
>> Here is what it looks like for Windows x64:
>> 
>> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
>> 
>> Here is another chart for Linux a64:
>> 
>> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
>> 
>> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
>> 
>> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
>> 
>> 
>> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
>> 
>> 
>> This could be added in a separate PR.
>> 
>> This PR has been tested with tier1-3 and passed.
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 625:
> 
>> 623:         if (size <= 0) {
>> 624:             // Do nothing
>> 625:         } else if (size < COPY_NATIVE_THRESHOLD && !src.overlaps(dst)) {
> 
> This is basically a conservative test - correct? E.g. we might end up cosidering two segments as overlapping even when they are not (because of offsets) - but that's ok, I actually think it's a good pragmatic solution.

Yes, it is conservative. We can tolerate overlaps in one direction (but not the other). We refrain from using these cases as they are unlikely, and checking would incur a performance price for all other (much more likely) cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1741982874

From swen at openjdk.org  Tue Sep  3 12:37:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 12:37:05 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v14]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <AHhtUxRuw2-ykcxNSA0ZePR3Q4L8ZPEQgP4jJ729TG4=.8b7da99d-57e3-4ebf-984c-6485b09d5414@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  Update src/java.base/share/classes/java/lang/System.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/c37dea67..72b99bd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=12-13

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

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

From redestad at openjdk.org  Tue Sep  3 12:44:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 12:44:20 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v14]
In-Reply-To: <AHhtUxRuw2-ykcxNSA0ZePR3Q4L8ZPEQgP4jJ729TG4=.8b7da99d-57e3-4ebf-984c-6485b09d5414@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <AHhtUxRuw2-ykcxNSA0ZePR3Q4L8ZPEQgP4jJ729TG4=.8b7da99d-57e3-4ebf-984c-6485b09d5414@github.com>
Message-ID: <MssOZji0Dnp-ySbSvMfI6Hi8bhpa_BdYfaCK_yOzFAE=.bd87c574-0a61-4175-a5f0-3f755c8900e6@github.com>

On Tue, 3 Sep 2024 12:37:05 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/System.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 397:

> 395: 
> 396:     /**
> 397:      * if string#coder() is Latin1 return the count of string#value() leading greater than zero, else return 0

Can you move this next to `countPositives`? 

Suggestion:

     * Count the number of leading positive, non-zero bytes in the range.


Technically this new routine is the "real" `countPositives` since, mathematically speaking, zero is neither positive nor negative. It's named like it is because I'm no mathematician, and now it might be better to rename away from that to disambiguate.. If you feel like it then please file an RFE to have `countPositives` renamed to `countNonNegatives`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1741995406

From coleenp at openjdk.org  Tue Sep  3 12:51:23 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Sep 2024 12:51:23 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
 <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
Message-ID: <HtglC84B6AAlUlSzO6X0ImhjEQqlsBbmdsnhHkvJdq8=.6c834908-0ce3-475e-898c-b800c1808e78@github.com>

On Tue, 27 Aug 2024 15:38:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>> 
>> MethodData does a lot of deallocations from metaspace because it's allocated racily.  It might be using Metaspace wrong.
>
>> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>> 
>> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.
> 
> I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.

@tstuefe Do you have more comments on this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2326439851

From epeter at openjdk.org  Tue Sep  3 12:54:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 3 Sep 2024 12:54:24 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
Message-ID: <e0mUyuGLj_YNJZesBnKa2KmswUOs9CEkPjULEeYL_Qc=.d968bd45-74b5-4e89-9a31-fddc0077698d@github.com>

On Mon, 2 Sep 2024 12:20:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolved

Ok. This is a huge change. And you do not just introduce changes to the VectorAPI and add Vector instructions. But you also add the scalar instructions.

Can you split this into at least 2 PR's that are smaller please?
- Scalar saturating instructions: they could even be made available to the user via `Integer.saturatingAdd` etc. Would that not be desired?
- Vector saturating instructions

I'm afraid that now you are not using the scalar ops individually at all, and they are only used as fallback when the vector-api code is not intrinsified. But how can we test this properly?

I'm just not very happy having to review 9K+ PR's ?

src/hotspot/cpu/x86/assembler_x86.cpp line 560:

> 558: }
> 559: 
> 560: bool Assembler::needs_evex(XMMRegister reg1, XMMRegister reg2, XMMRegister reg3) {

This is an ASSERT / DEBUG only method, correct? Do you want to `#ifdef ASSERT` it accordingly?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 914:

> 912:       case T_SHORT: vpminuw(dst, src1, src2, vlen_enc); break;
> 913:       case T_INT:   vpminud(dst, src1, src2, vlen_enc); break;
> 914:       case T_LONG:  evpminuq(dst, k0, src1, src2, false, vlen_enc); break;

Can you explain to me what the `k0` is and where it comes from?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 929:

> 927: }
> 928: 
> 929: void C2_MacroAssembler::vpuminmaxq(int opcode, XMMRegister dst, XMMRegister src1, XMMRegister src2, XMMRegister xtmp1, XMMRegister xtmp2, int vlen_enc) {

Either wrap all inputs or none ;)

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4705:

> 4703:     default:
> 4704:       fatal("Unsupported operation  %s", NodeClassNames[ideal_opc]);
> 4705:       break;

Did you mean to explicitly mention these cases as unsupported? If yes, please add a comment to the code why.

src/hotspot/cpu/x86/x86.ad line 6527:

> 6525:   %}
> 6526:   ins_pipe( pipe_slow );
> 6527: %}

Should change the `uminmax_reg` to indicate that it is a `vector` operation? The `format` already says `vector_uminmax_reg`... Because what if we one day want to use the name `uminmax_reg` for a scalar operation?

src/hotspot/share/opto/addnode.hpp line 194:

> 192: class SaturatingAddINode : public Node {
> 193: public:
> 194:   SaturatingAddINode(Node* in1, Node* in2) : Node(in1,in2) {}

Suggestion:

  SaturatingAddINode(Node* in1, Node* in2) : Node(in1, in2) {}

In other places below as well.

src/hotspot/share/opto/addnode.hpp line 198:

> 196:   virtual const Type* bottom_type() const { return TypeInt::INT; }
> 197:   virtual uint ideal_reg() const { return Op_RegI; }
> 198: };

Are these not supposed to inherit from the `AddNode`, and then override the corresponding methods? Or are you making them separate for a good reason?

src/hotspot/share/opto/addnode.hpp line 462:

> 460: //------------------------------UMaxINode---------------------------------------
> 461: // Maximum of 2 unsigned integers.
> 462: class UMaxLNode : public Node {

Here you comment it with `UMaxINode`, but below it is the `UMaxLNode`. The `-------xyz------` comments are really useless. But the semantics description is useful (though you again say integer instead of long here...).

src/hotspot/share/opto/matcher.hpp line 380:

> 378:   static BasicType vector_element_basic_type(const MachNode* use, const MachOper* opnd);
> 379:   static const Type* vector_element_type(const Node* n);
> 380:   static const Type* vector_element_type(const MachNode* use, const MachOper* opnd);

You should probably create your own section for this, since this is not about the **basic** type.

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2277262281
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741956515
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741964463
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741961089
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741971197
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741976975
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741990855
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741984047
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741987722
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1741997411

From vklang at openjdk.org  Tue Sep  3 12:58:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Sep 2024 12:58:24 GMT
Subject: Integrated: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails
 in linux-aarch64
In-Reply-To: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
Message-ID: <JF5vtfp_bqscuLxSUHRV8JwlIwzkBbgwDKtPDF-olFM=.3a8d0c4b-c9da-43f5-9938-0cf1c2d8a614@github.com>

On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.
> 
> So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.
> 
> There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.
> 
> I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.
> 
> The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.

This pull request has now been integrated.

Changeset: e0c46d58
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0c46d589b12aa644e12e4a4c9e84e035f7cf98d
Stats:     129 lines in 3 files changed: 106 ins; 3 del; 20 mod

8325397: sun/java2d/Disposer/TestDisposerRace.java fails in linux-aarch64

Reviewed-by: alanb

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

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

From ihse at openjdk.org  Tue Sep  3 13:02:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Sep 2024 13:02:55 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher
Message-ID: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>

As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.

This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 

All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

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

Commit messages:
 - Makefile changes needed for static-launcher and static-jdk-image targets
 - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

Changes: https://git.openjdk.org/jdk/pull/20837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339480
  Stats: 429 lines in 22 files changed: 351 ins; 5 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

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

From ihse at openjdk.org  Tue Sep  3 13:02:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Sep 2024 13:02:55 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <b4JPTQvVYy0YD37EA4fkGyoqdNDhmJoI3b5Nmap_Z5A=.8733d6e4-12a7-47da-9c90-87e1836d7a27@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

@jianglizhou Can you please check if there are any other contributors that should be acknowledged?

The `static-jdk` image is enough to run a simple HelloWorld java program; however it cannot yet run JTReg tests. The reason for this is, afaict, that the javac launcher is missing. I am planning to examine if it is possible to add a small shim `javac` launcher that calls the static `java` with the proper main class. (And similarly for the other launchers.) The goal here must, after all, be that we should be able to run the normal jtreg tests on the `static-jdk` image.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2326445877
PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2326452510

From aturbanov at openjdk.org  Tue Sep  3 13:03:26 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 3 Sep 2024 13:03:26 GMT
Subject: RFR: 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in
 linux-aarch64
In-Reply-To: <hJaTTxgMivUOfDk-37wWWEQ-QVjskBVXQNzl1poxKUM=.fbb7e5fb-b306-47b3-b200-5e5f38765719@github.com>
References: <6gjQhlGzRTlscLUi97wL3cb14W6Ao5-PT33FqYLFvYE=.8f7f2542-b413-4a28-8f39-29c910402bb9@github.com>
 <hJaTTxgMivUOfDk-37wWWEQ-QVjskBVXQNzl1poxKUM=.fbb7e5fb-b306-47b3-b200-5e5f38765719@github.com>
Message-ID: <LaF9dPI4cE7i16hZk7OoCTgtsQVQTrxWR4vxLSmEeq4=.043c6a95-f79e-499e-944b-5c9ddea5da86@github.com>

On Thu, 29 Aug 2024 17:06:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> My suspicion is that Condition::await() throws before having successfully reacquired the lock, and this exception is swallowed because Lock::unlock() then throws when invoke with an IllegalMonitorStateException as the current thread was not reestablished as the owner.
>> 
>> So this PR is intended to harden the reacquisition of await-ing methods in AQS and AQLS so that instead of throwing they spin-loop trying to reacquire the lock?at least a thread dump would show where the Thread is stuck trying to reacquire.
>> 
>> There's also the option of attempting to log a JFR event on the first reacquisition failure, but that might need to be done with a pre-created event as the cause of the failing acquisition may be an OOME.
>> 
>> I also needed to harden the TestDisposerRace itself, as it currently tries to provoke OOMEs but then proceeds to want to allocate objects used for the test itself. I'm not super-happy about the changes there, but they should be safer than before.
>> 
>> The first RuntimeException/Error encountered will be rethrown upon success to facilitate debugging.
>
> test/jdk/sun/java2d/Disposer/TestDisposerRace.java line 117:
> 
>> 115:         MyDisposerRecord disposerRecord = retryOnOOME(MyDisposerRecord::new);
>> 116: 
>> 117:         while(count > 0) {
> 
> nit
> Suggestion:
> 
>         while (count > 0) {

:(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20602#discussion_r1742022578

From epeter at openjdk.org  Tue Sep  3 13:06:27 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 3 Sep 2024 13:06:27 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
Message-ID: <qygI-vEd-CrsQ3GOAFkaAeD9KCyimWCWr7PieWmGUHk=.15b2eec8-2487-427d-a789-f13f19525ba3@github.com>

On Mon, 2 Sep 2024 12:20:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolved

Ok, I left a few more comments. I think this PR could definately be split. It would make it more reviewable for me.

src/hotspot/share/opto/vectornode.hpp line 148:

> 146: 
> 147: //===========================Vector=ALU=Operations=============================
> 148: class SaturatingVectorNode : public VectorNode {

Semantics description of Saturation would be appreciated :)

src/hotspot/share/opto/vectornode.hpp line 634:

> 632:   virtual int Opcode() const;
> 633: };
> 634: 

This could also be a separate PR. Or are they somehow inseparable from the "saturation" changes?

src/hotspot/share/prims/vectorSupport.hpp line 129:

> 127:     VECTOR_OP_SUSUB = 122,
> 128:     VECTOR_OP_UMIN = 123,
> 129:     VECTOR_OP_UMAX = 124,

Please keep the alignment consistent.

src/java.base/share/classes/java/lang/Integer.java line 1994:

> 1992:      * @return the greater of {@code a} and {@code b}
> 1993:      * @see java.util.function.BinaryOperator
> 1994:      * @since 1.8

Is this a copy error or did this already exist since `1.8`?

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 395:

> 393: 
> 394:     /* ============================================================================ */
> 395: 

These comment lines seem redundant...

test/jdk/jdk/incubator/vector/gen-template.sh line 317:

> 315: function gen_saturating_binary_op {
> 316:   echo "Generating binary op $1 ($2)..."
> 317: #  gen_op_tmpl $binary_scalar "$@"

Is this commented on purpose?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2277361678
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742016482
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742019985
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742021810
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742024534
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742026062
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742028394

From swen at openjdk.org  Tue Sep  3 13:09:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 13:09:37 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v3]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <zzi8Bf-hOSXzv2YlpoGQ6e_zV7pIi433ujaAO5z-6Jk=.5e3bcc97-913b-4900-9f62-dbe369f99136@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

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

  suggestion from @liach & @cl4es

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/a0aa9eac..83900373

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

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

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

From epeter at openjdk.org  Tue Sep  3 13:12:22 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 3 Sep 2024 13:12:22 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
Message-ID: <TQRt9w38cIX-gRkjVANWp0aZU5mNwcU95R09ISuTo7c=.4de988d2-bd8b-43fe-9b0c-15821f82d5e0@github.com>

On Mon, 2 Sep 2024 12:20:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolved

I really like the additions here. More scalar ops and vector ops are fantastic! But I'd like you to split it into scalar and vector changes. Because on both sides we'll have to do some review work to get it all right.

You did in fact add `java/lang` methods. I think you need to add tests for all of those. As well. That's going to be even more code to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2326480778
PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2326486187

From redestad at openjdk.org  Tue Sep  3 13:13:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 13:13:21 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v3]
In-Reply-To: <zzi8Bf-hOSXzv2YlpoGQ6e_zV7pIi433ujaAO5z-6Jk=.5e3bcc97-913b-4900-9f62-dbe369f99136@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <zzi8Bf-hOSXzv2YlpoGQ6e_zV7pIi433ujaAO5z-6Jk=.5e3bcc97-913b-4900-9f62-dbe369f99136@github.com>
Message-ID: <Fo08Rsp1QhBTS-HtRdZBkn7yH5BsAnbn-vihGej8Z_Q=.a61d3646-f7f6-45bb-b2b3-1c0ba4b90c70@github.com>

On Tue, 3 Sep 2024 13:09:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach & @cl4es

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 256:

> 254: 
> 255:     public static int slotSize(ClassDesc desc) {
> 256:         return isDoubleSlot(desc) ? 2 : 1;

No, I meant for this to be implemented in a new method, `paramSlotSize`, then call that instead of `slotSize` in the places where that's safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20747#discussion_r1742038452

From swen at openjdk.org  Tue Sep  3 13:22:41 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 13:22:41 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v15]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <vrRGx1m5pWOEosmW2_6F1V1aUpsZLL8EfFiMcpdKLK0=.c7b3b281-0e78-4955-8e18-bdf09aee5094@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  countGreaterThanZero -> CountNonNegatives

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/72b99bd7..431f55b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=13-14

  Stats: 175 lines in 6 files changed: 83 ins; 81 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From liach at openjdk.org  Tue Sep  3 13:47:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 13:47:26 GMT
Subject: Integrated: 8339214: Remove misleading
 CodeBuilder.loadConstant(Opcode, ConstantDesc)
In-Reply-To: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
Message-ID: <q2dpj8oY2B20RixeW4UxAj8_Sa_gb1TiI92q5b3wmjA=.cbe621c2-2c11-4b46-94c9-b70ef173ed8c@github.com>

On Thu, 29 Aug 2024 20:14:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and confusing. Users should almost always use `loadConstant(ConstantDesc)` for optimized instructions, or use specific factories `iconst_0` etc. or `bipush` with arguments or `LoadConstantInstruction.of` if they want to specify the exact type of LDC opcode.

This pull request has now been integrated.

Changeset: ad40a122
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad40a122d632d65052b71125c0dfd58c54e3a521
Stats:     207 lines in 10 files changed: 6 ins; 157 del; 44 mod

8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc)

Reviewed-by: asotona

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

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

From liach at openjdk.org  Tue Sep  3 13:48:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 13:48:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v14]
In-Reply-To: <MssOZji0Dnp-ySbSvMfI6Hi8bhpa_BdYfaCK_yOzFAE=.bd87c574-0a61-4175-a5f0-3f755c8900e6@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <AHhtUxRuw2-ykcxNSA0ZePR3Q4L8ZPEQgP4jJ729TG4=.8b7da99d-57e3-4ebf-984c-6485b09d5414@github.com>
 <MssOZji0Dnp-ySbSvMfI6Hi8bhpa_BdYfaCK_yOzFAE=.bd87c574-0a61-4175-a5f0-3f755c8900e6@github.com>
Message-ID: <GZTWwzNxKJb0MitrnkzsbT8mnfa5z8M3-vk5sO6Y8P8=.160971ff-a445-4a4c-974b-f9dfc1f6f372@github.com>

On Tue, 3 Sep 2024 12:42:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/System.java
>>   
>>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 397:
> 
>> 395: 
>> 396:     /**
>> 397:      * if string#coder() is Latin1 return the count of string#value() leading greater than zero, else return 0
> 
> Can you move this next to `countPositives`? 
> 
> Suggestion:
> 
>      * Count the number of leading positive, non-zero bytes in the range.
> 
> 
> Technically this new routine is the "real" `countPositives` since, mathematically speaking, zero is neither positive nor negative. It's named like it is because I'm no mathematician, and now it might be better to rename away from that to disambiguate.. If you feel like it then please file an RFE to have `countPositives` renamed to `countNonNegatives`

We might rename these to `countAscii` and `countModifiedUtf8Compatible`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1742093845

From jvernee at openjdk.org  Tue Sep  3 13:49:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
Message-ID: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>

As discussed in the JBS issue:

FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`

However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.

The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.

<details>
<summary>Performance numbers</summary>
x64:

before:

Benchmark             Mode  Cnt   Score   Error  Units
Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op


after:

Benchmark             Mode  Cnt   Score   Error  Units
Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op


aarch64:

before:

Benchmark             Mode  Cnt   Score   Error  Units
Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op


after:

Benchmark             Mode  Cnt   Score   Error  Units
Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op

</details>

As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.

Testing: tier 1-4

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

Commit messages:
 - Add s390 changes
 - Merge branch 'master' into LoadVMTraget
 - Don't save/restore LR/CR + resolve_jobject on s390
 - eyeball other platforms
 - call stub from upcall stub
 - reinit_heap_base
 - eyeball other platforms
 - Only test on Linux/AArch64
 - aarch64 impl
 - load vmentry in on_entry using special stub
 - ... and 8 more: https://git.openjdk.org/jdk/compare/0e6bb514...8dcb14ff

Changes: https://git.openjdk.org/jdk/pull/20479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337753
  Stats: 334 lines in 23 files changed: 257 ins; 26 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/20479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20479/head:pull/20479

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

From amitkumar at openjdk.org  Tue Sep  3 13:49:57 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <6CeWpXBf60zq-H8SCQRoCP76TfwVHgSbxPG1RFR7E_8=.34c40871-4ae8-40a6-bc6f-94533c485903@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

RuntimeAddress will not work for s390x. @JornVernee would you please apply these changes.

Thanks @TheRealMDoerr for pointing it out. I will create a JBS issue for implementing `resolve_global_jobject`. 


diff --git a/src/hotspot/cpu/s390/upcallLinker_s390.cpp b/src/hotspot/cpu/s390/upcallLinker_s390.cpp
index 1b07522858f..8baad40a519 100644
--- a/src/hotspot/cpu/s390/upcallLinker_s390.cpp
+++ b/src/hotspot/cpu/s390/upcallLinker_s390.cpp
@@ -216,10 +216,11 @@ address UpcallLinker::make_upcall_stub(jobject receiver, Symbol* signature,
   arg_shuffle.generate(_masm, shuffle_reg, abi._shadow_space_bytes, frame::z_jit_out_preserve_size);
   __ block_comment("} argument_shuffle");
 
-  __ block_comment("load target {");
+  __ block_comment("load_target {");
   __ load_const_optimized(Z_ARG1, (intptr_t)receiver);
-  __ call(RuntimeAddress(StubRoutines::upcall_stub_load_target())); // load taget Method* into Z_method
-  __ block_comment("} load target");
+  __ load_const_optimized(call_target_address, StubRoutines::upcall_stub_load_target());
+  __ call(call_target_address); // load taget Method* into Z_method
+  __ block_comment("} load_target");
 
   __ z_lg(call_target_address, Address(Z_method, in_bytes(Method::from_compiled_offset())));
   __ call(call_target_address);

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

Changes requested by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20479#pullrequestreview-2276394431

From jvernee at openjdk.org  Tue Sep  3 13:49:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <9_oOgD6Q5GisXSkq98pAsMwDZAyHEfAWLf5IUFWKIks=.cf7ac1ce-62b4-4c1e-8b0c-0f3ff06c9618@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

I had to adjust the stub size on x64 when running on fastdebug/shenandoah. That may also be needed on other platforms except for aarch64), but I can't test there.

To find the right stub size, just increase `upcall_stub_code_base_size` to a high number (e.g. 2048), and then run this program:


import java.lang.foreign.*;
import java.lang.invoke.*;

public class Main {
    public static void main(String[] args) throws Throwable {
        try (Arena arena = Arena.ofConfined()) {
            MemorySegment stub = Linker.nativeLinker().upcallStub(
                MethodHandles.empty(MethodType.methodType(void.class)),
                FunctionDescriptor.ofVoid(),
                arena);
        }   
    }
}



$ javac -d classes Main.java
$ java -cp classes -XX:+UseShenandoahGC -XX:+LogCompilation Main
$ grep upcall_stub -A 1 hotspot_pid*
<blob name='upcall_stub_()V' total_size='1360'>
<sect index='1' capacity='1360' size='1195' remaining='165'/>


Then set `upcall_stub_code_base_size` to be bigger than `size`.

Using a static stub is still a bit slower, but much more in line with the performance of inline loads:


Current:

Benchmark                  Mode  Cnt    Score   Error  Units
QSort.panama_upcall_qsort  avgt   30  608.953 ? 3.047  ns/op


Fully C++:

Benchmark                  Mode  Cnt    Score   Error  Units
QSort.panama_upcall_qsort  avgt   30  725.142 ? 2.718  ns/op   ~19% slower


Static stub:

Benchmark                  Mode  Cnt    Score   Error  Units
QSort.panama_upcall_qsort  avgt   30  627.661 ? 2.099  ns/op   ~3% slower


I think that's a good compromise. (Although I wish the C++ code was just as fast, as it's much nicer)

> Some of the DecoratorSet should be applicable and improve performance.

I gave `AS_NO_KEEPALIVE` a try. I'm not sure if that's correct, but it didn't really change performance. I'm not sure what other decorator would apply. I was looking at `ACCESS_READ`, but it seems that that can not be used for these loads.

I've added the implementations with the stubs, I had to eyeball `s390, ppc, and rsicv, so testing is still needed on those platforms (GHA will do the cross builds).

I also spent quite a while messing with the test. This test is quite unstable, because it creates a new thread pool for each test case, and then calls `ExecutorService::shutdownNow`, which doesn't allow submitted tasks to finish. It was running out of memory on some of the mac machine we test on in CI. I've made several attempts to make it more stable, but all of those resulted in the issue no longer being reproduced. For now I've restricted the test to linux/aarch64, since that's where we see the issue, and it seems stable enough to pass every time at least in out CI. If it causes issues though, I think we might have to just drop the test, or maybe mark it as `/manual`, so it doesn't run in CI.

I'll be away until September. Will pick this back up then.

With the latest version, we are slightly faster than the baseline:


baseline:

Benchmark                  Mode  Cnt    Score   Error  Units
QSort.panama_upcall_qsort  avgt   30  635.047 ? 2.181  ns/op

Patched:

Benchmark                  Mode  Cnt    Score   Error  Units
QSort.panama_upcall_qsort  avgt   30  625.385 ? 2.442  ns/op


@TheRealMDoerr Thanks for all the suggestions!

src/hotspot/cpu/x86/upcallLinker_x86_64.cpp line 311:

> 309:                     Address(rbx, java_lang_invoke_ResolvedMethodName::vmtarget_offset()),
> 310:                     noreg, noreg);
> 311:   __ movptr(Address(r15_thread, JavaThread::callee_target_offset()), rbx); // just in case callee is deoptimized

FWIW, I tried to move this code to `UpcallLinker::on_entry`, but there is a speed cost to that (of around 10ns on my machine). Doing that results in several out-of-line calls to `AccessInternal::RuntimeDispatch<...>::_load_at_func` to load the values. It seems like a tradeoff between speed and space (in the code cache). I went with speed here.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2273455863
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2277864015
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2278175462
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2278557487
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2326568409
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1706122881

From mdoerr at openjdk.org  Tue Sep  3 13:49:57 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <r4r9kks7dGsAoLB1TnFiD-4AflY65_GiKMUHRIzdlKU=.e77a0457-a909-4be2-a561-b602160513d2@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

Can't we do these nasty loads in C++ code and use `set_vm_result_2` in `UpcallLinker::on_entry`?
The GC barriers can generate excessive amounts of code with some GCs. I guess that upcalls are less performance critical, so I'd prefer the other solution. Maybe the C++ code can get optimized better, too.

Some of the `DecoratorSet` should be applicable and improve performance. If that doesn't help enough, maybe we should implement a dedicated static stub? There's no need to have the code replicated in each upcall stub.

Also note that each `load_heap_oop` may save and restore registers which is actually only needed once.

Regarding PPC64, I think that we could avoid PRESERVATION_FRAME_LR_GP_FP_REGS if we rearrange it such that the `load_heap_oop` is done at a place where the volatile regs are not live. But seems like this optimization is not available for other platforms.

Some performance related remarks:

- You could use `resolve_global_jobject` which is shorter and faster and exists on most platforms.
- Using `vm_result_2` is no longer needed. The Method* can be directly passed in the method reg (or loaded from `callee_target`).
- If you call the stub from assembler instead of from C++ you should be able to save some extra stuff like the frame.

I'll check the PPC64 code later.

@offamitkumar: Can you take a look at the s390 code, please? The cross build has failed. For the future: You may want to implement `resolve_global_jobject` which is shorter and faster and available on the other platforms.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4778:

> 4776:     StubCodeMark mark(this, "StubRoutines", "upcall_stub_load_target");
> 4777:     address start = __ pc();
> 4778:     __ save_LR_CR(R0);

I think `save_LR_CR` and `restore_LR_CR` should get removed, too. CR is not live and LR is preserved everywhere below. But, I'll check this later.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2275524582
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2275707529
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2278240985
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2325103457
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1713844568

From jvernee at openjdk.org  Tue Sep  3 13:49:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <r4r9kks7dGsAoLB1TnFiD-4AflY65_GiKMUHRIzdlKU=.e77a0457-a909-4be2-a561-b602160513d2@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <r4r9kks7dGsAoLB1TnFiD-4AflY65_GiKMUHRIzdlKU=.e77a0457-a909-4be2-a561-b602160513d2@github.com>
Message-ID: <RlALNVUs42QhIF-FiVTHy4DTpzvURLRumwTzQ2wh4bI=.c7f522de-edf4-46bc-b57a-7cf7a37bae81@github.com>

On Thu, 8 Aug 2024 10:51:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Can't we do these nasty loads in C++ code and use set_vm_result_2 in UpcallLinker::on_entry?

That's what I tried. I got a ~20% hit to execution time.

> I guess that upcalls are less performance critical

Why so? They are certainly much more rare than downcalls, but when they _are_ used, I think we'd like them to be fast.

> Maybe the C++ code can get optimized better, too.

I [tried](https://github.com/openjdk/jdk/commit/a2614ab77ef0ed493a819b970b31b939126c3da5) optimizing things by moving the accessors to `javaClasses.inline.hpp`, that helped the generated code a bit, but it didn't really improve speed. I think the problem is that we don't know at C++ compile time which barrier we need to use, since the GC is selected at runtime, while we do know when generating the stub. So, if we use C++, there will always be an out-of-line dispatch to the `_load_at` function for the particular GC.

> Some of the DecoratorSet should be applicable and improve performance. If that doesn't help enough, maybe we should implement a dedicated static stub? There's no need to have the code replicated in each upcall stub.

That's a good idea. If we can make that work, I'm all for it.

P.S. giving that a try now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2275658037
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2275861261

From mdoerr at openjdk.org  Tue Sep  3 13:49:57 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <9_oOgD6Q5GisXSkq98pAsMwDZAyHEfAWLf5IUFWKIks=.cf7ac1ce-62b4-4c1e-8b0c-0f3ff06c9618@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <9_oOgD6Q5GisXSkq98pAsMwDZAyHEfAWLf5IUFWKIks=.cf7ac1ce-62b4-4c1e-8b0c-0f3ff06c9618@github.com>
Message-ID: <nDKB8mFOGf2PFkWEcPlu4XiBnNzJ4xzizi9w0nNYv5A=.2a7c0d51-f8ca-4018-aca5-b191ab1a5f57@github.com>

On Fri, 9 Aug 2024 12:44:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think that's a good compromise. (Although I wish the C++ code was just as fast, as it's much nicer)

Agreed.

> I'm not sure what other decorator would apply.

I think `ON_STRONG_OOP_REF` and `IS_NOT_NULL` could also be used. But, I guess that wouldn't make it fast enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2278057468

From jvernee at openjdk.org  Tue Sep  3 13:49:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 3 Sep 2024 13:49:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <6CeWpXBf60zq-H8SCQRoCP76TfwVHgSbxPG1RFR7E_8=.34c40871-4ae8-40a6-bc6f-94533c485903@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <6CeWpXBf60zq-H8SCQRoCP76TfwVHgSbxPG1RFR7E_8=.34c40871-4ae8-40a6-bc6f-94533c485903@github.com>
Message-ID: <0WNgksf6ekZFo6urALPuINQ05farx7pAzkmw2sZqAB0=.a2e37bb0-04bd-4ac5-ab5a-9101813a2981@github.com>

On Tue, 3 Sep 2024 04:52:08 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> RuntimeAddress will not work for s390x. @JornVernee would you please apply these changes.
> 
> Thanks @TheRealMDoerr for pointing it out. I will create a JBS issue for implementing `resolve_global_jobject`. 
> 
> 
> diff --git a/src/hotspot/cpu/s390/upcallLinker_s390.cpp b/src/hotspot/cpu/s390/upcallLinker_s390.cpp
> index 1b07522858f..8baad40a519 100644
> --- a/src/hotspot/cpu/s390/upcallLinker_s390.cpp
> +++ b/src/hotspot/cpu/s390/upcallLinker_s390.cpp
> @@ -216,10 +216,11 @@ address UpcallLinker::make_upcall_stub(jobject receiver, Symbol* signature,
>    arg_shuffle.generate(_masm, shuffle_reg, abi._shadow_space_bytes, frame::z_jit_out_preserve_size);
>    __ block_comment("} argument_shuffle");
>  
> -  __ block_comment("load target {");
> +  __ block_comment("load_target {");
>    __ load_const_optimized(Z_ARG1, (intptr_t)receiver);
> -  __ call(RuntimeAddress(StubRoutines::upcall_stub_load_target())); // load taget Method* into Z_method
> -  __ block_comment("} load target");
> +  __ load_const_optimized(call_target_address, StubRoutines::upcall_stub_load_target());
> +  __ call(call_target_address); // load taget Method* into Z_method
> +  __ block_comment("} load_target");
>  
>    __ z_lg(call_target_address, Address(Z_method, in_bytes(Method::from_compiled_offset())));
>    __ call(call_target_address);

@offamitkumar thanks, I've added those changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2326422537

From liach at openjdk.org  Tue Sep  3 13:57:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 13:57:21 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v3]
In-Reply-To: <JoSeYIgfRBiJz-2lGVh7VlwA04bK-KDH2PS0IgLOxbU=.4247847f-c292-458f-8bba-6b4b406a25a9@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <JoSeYIgfRBiJz-2lGVh7VlwA04bK-KDH2PS0IgLOxbU=.4247847f-c292-458f-8bba-6b4b406a25a9@github.com>
Message-ID: <uYGXLD5igZU_xc-XOr31WLbME8BJDcxA_uUpguBRdUs=.b3aaa989-1b37-440d-a21a-6246451dd0a5@github.com>

On Tue, 3 Sep 2024 12:23:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

This migration of write 0 to skip reveals that they are different. Good RFE. (Maybe we can make the BufWriterImpl buffer growth to allocate non-initialized array after the write 0 fixes)

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 192:

> 190:     }
> 191: 
> 192:     public void skip(int skipSize) {

Conceptually I would prefer to make such an API return an int for skipped index so we can more easily patch later. But that is really optional.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 240:

> 238:     public void writeIndexOrZero(PoolEntry entry) {
> 239:         if (entry == null || entry.index() == 0)
> 240:             skip(2);

Writing `0` CP index for `null` is mandated by the attributes that do so. https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.7.24-300-D-A.1

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 598:

> 596:         bytecodesBufWriter.writeIndex(ref);
> 597:         bytecodesBufWriter.writeU1(count);
> 598:         bytecodesBufWriter.skip(1);

`0` is mandated: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokeinterface

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 604:

> 602:         writeBytecode(INVOKEDYNAMIC);
> 603:         bytecodesBufWriter.writeIndex(ref);
> 604:         bytecodesBufWriter.skip(2);

`0` is mandated: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic

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

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20780#pullrequestreview-2277504778
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1742099316
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1742100573
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1742102738
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1742102983

From duke at openjdk.org  Tue Sep  3 14:03:20 2024
From: duke at openjdk.org (fitzsim)
Date: Tue, 3 Sep 2024 14:03:20 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <fgXfd-S1Ew6vwNbw6O7qVz9rv_Cy24qcKgiApyHPSpE=.d481320a-ccf0-45f3-9cca-37d884915880@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
 <fgXfd-S1Ew6vwNbw6O7qVz9rv_Cy24qcKgiApyHPSpE=.d481320a-ccf0-45f3-9cca-37d884915880@github.com>
Message-ID: <fApwm9IO8TbPGr5zKlNYXxbHNgUK2QwhmJL-ISgx0Gk=.70b80c46-e996-4990-af19-5c2ed66686b2@github.com>

On Mon, 2 Sep 2024 16:02:31 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions
>
> I can't review, as I ported the native code changes. On that note, can you make sure I'm credited as co-author using [/contributor](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor) please? 
> 
> i.e. /contributor add @gnu-andrew
> 
> You may want to also comment on [JDK-8185896](https://bugs.openjdk.org/browse/JDK-8185896) which is about adding Zip64 tests.

Hi @gnu-andrew, I have corrected your contributor status, thank you for the reminder.

I do not have access to comment on https://bugs.openjdk.org/browse/JDK-8185896.  Can you please add a comment from me that says:

"I have added to https://github.com/openjdk/jdk/pull/19678 two ZIP64 test cases:  one for ZIP64 extensions added implicitly due to one of the CEN fields being too large to represent, and one for ZIP64 extensions that have been added explicitly even though no CEN field required them.

It is not complete coverage -- the "implicit" test only tests the field for the total number of entries.  But the coverage they provide may be enough to warrant closing JDK-8185896.

The test cases are fast and portable back to OpenJDK  8, and do not require significant disk space, so they can be run unconditionally as part of the default `jtreg` test set."

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2326605880

From skuksenko at openjdk.org  Tue Sep  3 14:06:22 2024
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Tue, 3 Sep 2024 14:06:22 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
Message-ID: <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>

On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Code more clear
>  - Tests changes
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Removed trailing whitespace
>  - MutableBigInteger.leftShift(int) optimization

It would be nice to see some benchmarks where it gives performance benefits.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2326612409

From swen at openjdk.org  Tue Sep  3 14:07:39 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 14:07:39 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v4]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <7ClosIn7MwVh8lb9GlQNM0dR8j73gigpXnK7AMkA3RA=.167d210c-11c4-4734-9c8b-29da3a625e20@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

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

  add benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/83900373..105ffc01

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

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

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

From mbaesken at openjdk.org  Tue Sep  3 14:13:47 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 14:13:47 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include message
 text and last error information
Message-ID: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>

When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :

java.lang.RuntimeException: Cannot allocate memory
       at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
       at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
       at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
       at PermissionTest.childrenWithPermission(PermissionTest.java:84)
       at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
       at java.base/java.lang.reflect.Method.invoke(Method.java:573)
       at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
       at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
       at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
       at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
       at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
       at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
       at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
       at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
       at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)


Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

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

Commit messages:
 - JDK-8339487

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

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

From swen at openjdk.org  Tue Sep  3 14:15:41 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 14:15:41 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v5]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <7hvhtiDYfDI09xsU9N7_8S9jNj2Z4yLXRSG6M9buQB4=.fe782a65-39df-4175-b8cb-4261f68191dc@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

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

  suggestion from @cl4es

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/105ffc01..972ba60d

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

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

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

From jvernee at openjdk.org  Tue Sep  3 14:20:22 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 3 Sep 2024 14:20:22 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <RxKsoLiyPz5f70eQ9-9QVc-df1kdh3GRfacZRS_6tBU=.ed10432d-f98f-4eb9-8391-9131e537ae36@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

src/hotspot/share/runtime/frame.cpp line 1132:

> 1130:   }
> 1131:   _cb->as_upcall_stub()->oops_do(f, *this);
> 1132: }

This was previously handled by overriding `preserve_callee_argument_oops` in `UpcallStub` as `ShouldNotReachHere`. That function was removed though. We should really have a check like this, since it helps rule out missed handling of the receiver handle which can cause GC issues, so I've added this here.

I can move it to a separate PR as well, if preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1742153421

From swen at openjdk.org  Tue Sep  3 14:30:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 14:30:38 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v4]
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <2a84s0JHW3dfK1e2T4-KwQh6eR22htwlqWBYZEjo5Pc=.5a53da0b-2c93-4e6d-8db7-8ef08ef805ff@github.com>

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

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

  revert skip

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20780/files
  - new: https://git.openjdk.org/jdk/pull/20780/files/d7227a9c..058d8dad

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

  Stats: 12 lines in 5 files changed: 1 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20780.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20780/head:pull/20780

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

From swen at openjdk.org  Tue Sep  3 14:35:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 14:35:20 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v14]
In-Reply-To: <GZTWwzNxKJb0MitrnkzsbT8mnfa5z8M3-vk5sO6Y8P8=.160971ff-a445-4a4c-974b-f9dfc1f6f372@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <AHhtUxRuw2-ykcxNSA0ZePR3Q4L8ZPEQgP4jJ729TG4=.8b7da99d-57e3-4ebf-984c-6485b09d5414@github.com>
 <MssOZji0Dnp-ySbSvMfI6Hi8bhpa_BdYfaCK_yOzFAE=.bd87c574-0a61-4175-a5f0-3f755c8900e6@github.com>
 <GZTWwzNxKJb0MitrnkzsbT8mnfa5z8M3-vk5sO6Y8P8=.160971ff-a445-4a4c-974b-f9dfc1f6f372@github.com>
Message-ID: <J2EwZ1IBNUN5UaIor-BFYXhzrIYO4nfZwv3hayStLSo=.ed772eec-088b-4472-af87-e6409b16edc7@github.com>

On Tue, 3 Sep 2024 13:45:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 397:
>> 
>>> 395: 
>>> 396:     /**
>>> 397:      * if string#coder() is Latin1 return the count of string#value() leading greater than zero, else return 0
>> 
>> Can you move this next to `countPositives`? 
>> 
>> Suggestion:
>> 
>>      * Count the number of leading positive, non-zero bytes in the range.
>> 
>> 
>> Technically this new routine is the "real" `countPositives` since, mathematically speaking, zero is neither positive nor negative. It's named like it is because I'm no mathematician, and now it might be better to rename away from that to disambiguate.. If you feel like it then please file an RFE to have `countPositives` renamed to `countNonNegatives`
>
> We might rename these to `countAscii` and `countModifiedUtf8Compatible`.

ascii includes '\0', `CountModifiedUtf8Compatible` Newbies don't seem to know what it means

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1742180530

From alanb at openjdk.org  Tue Sep  3 14:39:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 14:39:18 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <e5MzcisOQBZIvsBtNsaBO7ofzFtWBlm_L_UyjC0zWhU=.8e9a0d67-f75d-43e9-8e8b-d52585357284@github.com>

On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

ProcessHandle.children doesn't specify RuntimeException so I assume that needs to be looked into.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2326698089

From mbaesken at openjdk.org  Tue Sep  3 14:48:21 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 14:48:21 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <e5MzcisOQBZIvsBtNsaBO7ofzFtWBlm_L_UyjC0zWhU=.8e9a0d67-f75d-43e9-8e8b-d52585357284@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <e5MzcisOQBZIvsBtNsaBO7ofzFtWBlm_L_UyjC0zWhU=.8e9a0d67-f75d-43e9-8e8b-d52585357284@github.com>
Message-ID: <kjcZo5b3F0Po3pabrNvVJU1XZZGFAPP-8By5olw-GTU=.5c8161a2-18b0-489a-8518-039e52c4b75c@github.com>

On Tue, 3 Sep 2024 14:37:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ProcessHandle.children doesn't specify RuntimeException so I assume that needs to be looked into.

Should we add RuntimeException to the javadoc ?
Or throw some other exception ?
But I think the behavior is present for some time, it can happen that sysctl occasionally/seldom fails for various reasons.
We saw this 2-3 times per year in out tests.
But then a clearer exception would be helpful.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2326719248

From redestad at openjdk.org  Tue Sep  3 14:56:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 14:56:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v15]
In-Reply-To: <vrRGx1m5pWOEosmW2_6F1V1aUpsZLL8EfFiMcpdKLK0=.c7b3b281-0e78-4955-8e18-bdf09aee5094@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <vrRGx1m5pWOEosmW2_6F1V1aUpsZLL8EfFiMcpdKLK0=.c7b3b281-0e78-4955-8e18-bdf09aee5094@github.com>
Message-ID: <NmwcFN-axM5VuZErk7Hgy1-4pgvelloL1A4wWH2tOoc=.610b69ea-1554-4225-bfbe-5c3a5d9eda42@github.com>

On Tue, 3 Sep 2024 13:22:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   countGreaterThanZero -> CountNonNegatives

src/java.base/share/classes/java/lang/StringCoding.java line 41:

> 39:      * Count the number of String::value leading non-negatives in the range.
> 40:      */
> 41:     public static int countNonNegatives(String s) {

No, this is wrong, `NonNegatives` implies zeroes. I meant that `countPositives` should be renamed `countNonNegatives` in a future enhancement to more precisely reflect what it does. That's finicky since it's intrinsified and requires coordination with runtime code, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1742216866

From mbaesken at openjdk.org  Tue Sep  3 14:57:18 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 14:57:18 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <gO-eaudwJSIT0GZ8MuOXqtufAbaXpW06X53_pjrAcT0=.aef9974e-e034-44e4-90a0-edd21693fe64@github.com>

On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

GHA linux-x64 / build (debug)    get jtreg setp failed; unrelated

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2326740083

From redestad at openjdk.org  Tue Sep  3 15:01:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 15:01:22 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v14]
In-Reply-To: <J2EwZ1IBNUN5UaIor-BFYXhzrIYO4nfZwv3hayStLSo=.ed772eec-088b-4472-af87-e6409b16edc7@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <AHhtUxRuw2-ykcxNSA0ZePR3Q4L8ZPEQgP4jJ729TG4=.8b7da99d-57e3-4ebf-984c-6485b09d5414@github.com>
 <MssOZji0Dnp-ySbSvMfI6Hi8bhpa_BdYfaCK_yOzFAE=.bd87c574-0a61-4175-a5f0-3f755c8900e6@github.com>
 <GZTWwzNxKJb0MitrnkzsbT8mnfa5z8M3-vk5sO6Y8P8=.160971ff-a445-4a4c-974b-f9dfc1f6f372@github.com>
 <J2EwZ1IBNUN5UaIor-BFYXhzrIYO4nfZwv3hayStLSo=.ed772eec-088b-4472-af87-e6409b16edc7@github.com>
Message-ID: <Jn9Q854lKLwlN83ECBwXatN4oVTAlxaRkC7PLABrr_U=.0fb4add3-de9c-43f5-938d-cec9a3f268b7@github.com>

On Tue, 3 Sep 2024 14:32:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> We might rename these to `countAscii` and `countModifiedUtf8Compatible`.
>
> ascii includes '\0', `CountModifiedUtf8Compatible` Newbies don't seem to know what it means

I think naming internal low-level methods based precisely on what they do rather than their intended purpose is fine: we're counting positives and zeros in a byte array. Good! Higher level API methods called `isAscii(byte[] utf8Bytes)` et.c. which calls the low-level methods? Also good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1742225537

From swen at openjdk.org  Tue Sep  3 15:24:02 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 15:24:02 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v16]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <1rh1WHwR2rKyQDCZW-Wr8dbT76050jjj3SKB9y48P_M=.ff253b06-7ba5-4f0c-944c-1d272993103e@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

 - suggestion from @cl4es
 - Revert "countGreaterThanZero -> CountNonNegatives"
   
   This reverts commit 431f55b46daf86fe9f2e24a2587eba8f65d847ff.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/431f55b4..c0e425cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=14-15

  Stats: 160 lines in 6 files changed: 72 ins; 72 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From mcimadamore at openjdk.org  Tue Sep  3 15:26:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Sep 2024 15:26:22 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <_eQBOo3xh4ggMDO8wfqrOe3ovf2dOelyPSFHRMOvkGU=.3e183b75-2e16-4f61-abf4-35e92347cd22@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 637:

> 635:             for (; offset < limit; offset += 8) {
> 636:                 final long v = SCOPED_MEMORY_ACCESS.getLong(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcOffset + offset);
> 637:                 SCOPED_MEMORY_ACCESS.putLong(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstOffset + offset, v);

I've been digging a bit deeper on why we can get away w/o aligned access (both here and for `fill`). It turns out that, conveniently, var handles use `Unsafe::getXYZUnaligned` for plain set/get. This means that the intrinsics will deal with unaligned access accordingly, depending on the platform (either by splitting into multiple accesses, or by issuing an unaligned access on platforms that support that).

This means we can write "simple" code, and expect C2 to rewrite it the most optimal way. We should probably add a comment in this direction (both for `fill` and `copy`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1742260984

From mcimadamore at openjdk.org  Tue Sep  3 15:26:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Sep 2024 15:26:22 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <_eQBOo3xh4ggMDO8wfqrOe3ovf2dOelyPSFHRMOvkGU=.3e183b75-2e16-4f61-abf4-35e92347cd22@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <_eQBOo3xh4ggMDO8wfqrOe3ovf2dOelyPSFHRMOvkGU=.3e183b75-2e16-4f61-abf4-35e92347cd22@github.com>
Message-ID: <qPOgH8bFsZzG9ru2DJKSNb9aZM3-NlQh7tb4Mr45XEg=.9f30ca99-e534-4282-a8fb-47c360468799@github.com>

On Tue, 3 Sep 2024 15:22:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
>> 
>> Here is what it looks like for Windows x64:
>> 
>> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
>> 
>> Here is another chart for Linux a64:
>> 
>> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
>> 
>> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
>> 
>> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
>> 
>> 
>> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
>> 
>> 
>> This could be added in a separate PR.
>> 
>> This PR has been tested with tier1-3 and passed.
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 637:
> 
>> 635:             for (; offset < limit; offset += 8) {
>> 636:                 final long v = SCOPED_MEMORY_ACCESS.getLong(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcOffset + offset);
>> 637:                 SCOPED_MEMORY_ACCESS.putLong(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstOffset + offset, v);
> 
> I've been digging a bit deeper on why we can get away w/o aligned access (both here and for `fill`). It turns out that, conveniently, var handles use `Unsafe::getXYZUnaligned` for plain set/get. This means that the intrinsics will deal with unaligned access accordingly, depending on the platform (either by splitting into multiple accesses, or by issuing an unaligned access on platforms that support that).
> 
> This means we can write "simple" code, and expect C2 to rewrite it the most optimal way. We should probably add a comment in this direction (both for `fill` and `copy`.

Separately, I wonder if it would make sense to put all these "tricky" routines off to one side - e.g. `BulkSegmentSupport`, so that we don't make `AbstractMemorySegmentImpl` even bigger than it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1742262076

From duke at openjdk.org  Tue Sep  3 15:32:48 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 3 Sep 2024 15:32:48 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler
In-Reply-To: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
Message-ID: <rKfjYaKAd6scLjskshZz4ORwlwL-Oytd2rP69mYObM8=.aded08ce-9753-48f5-8e65-c79238ebf045@github.com>

On Mon, 2 Sep 2024 12:25:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named VirtualThreadSchedulerMXBean and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
> 
> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
> 
> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
> 
> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).

Typo (`imp`???`impl`):

The?`BaseVirtualThreadSchedulerImpl` hierarchy can?be?`sealed`:

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 56:

> 54:      * Base implementation of VirtualThreadSchedulerMXBean.
> 55:      */
> 56:     private abstract static class BaseVirtualThreadSchedulerImpl

Suggestion:

    private abstract static sealed class BaseVirtualThreadSchedulerImpl

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 59:

> 57:             implements VirtualThreadSchedulerMXBean {
> 58: 
> 59:         abstract void impSetParallelism(int size);

Suggestion:

        abstract void implSetParallelism(int size);

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 64:

> 62:         public final void setParallelism(int size) {
> 63:             Util.checkControlAccess();
> 64:             impSetParallelism(size);

Suggestion:

            implSetParallelism(size);

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 97:

> 95:      * implemented with continuations + scheduler.
> 96:      */
> 97:     private static class VirtualThreadSchedulerImpl extends BaseVirtualThreadSchedulerImpl {

Suggestion:

    private static final class VirtualThreadSchedulerImpl extends BaseVirtualThreadSchedulerImpl {

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 119:

> 117: 
> 118:         @Override
> 119:         void impSetParallelism(int size) {

Suggestion:

        void implSetParallelism(int size) {

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 159:

> 157:      * by platform threads.
> 158:      */
> 159:     private static class BoundVirtualThreadSchedulerImpl extends BaseVirtualThreadSchedulerImpl {

Suggestion:

    private static final class BoundVirtualThreadSchedulerImpl extends BaseVirtualThreadSchedulerImpl {

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 167:

> 165: 
> 166:         @Override
> 167:         void impSetParallelism(int size) {

Suggestion:

        void implSetParallelism(int size) {

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

PR Review: https://git.openjdk.org/jdk/pull/20816#pullrequestreview-2276238096
PR Review: https://git.openjdk.org/jdk/pull/20816#pullrequestreview-2276600238
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741551781
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741310375
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741310424
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741552166
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741310517
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741552822
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1741310573

From alanb at openjdk.org  Tue Sep  3 15:32:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 15:32:47 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler
Message-ID: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>

This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named VirtualThreadSchedulerMXBean and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.

The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.

jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).

(The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).

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

Commit messages:
 - Sync up from loom repo
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20816/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338890
  Stats: 576 lines in 23 files changed: 523 ins; 17 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/20816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20816/head:pull/20816

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

From alanb at openjdk.org  Tue Sep  3 15:34:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 15:34:25 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <kjcZo5b3F0Po3pabrNvVJU1XZZGFAPP-8By5olw-GTU=.5c8161a2-18b0-489a-8518-039e52c4b75c@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <e5MzcisOQBZIvsBtNsaBO7ofzFtWBlm_L_UyjC0zWhU=.8e9a0d67-f75d-43e9-8e8b-d52585357284@github.com>
 <kjcZo5b3F0Po3pabrNvVJU1XZZGFAPP-8By5olw-GTU=.5c8161a2-18b0-489a-8518-039e52c4b75c@github.com>
Message-ID: <fagdroWUpWLeprNz6NRp8aYibeYmkUDi-waGmulRn50=.614ce3aa-c701-4848-962c-dc78203fb358@github.com>

On Tue, 3 Sep 2024 14:46:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > ProcessHandle.children doesn't specify RuntimeException so I assume that needs to be looked into.
> 
> Should we add RuntimeException to the javadoc ? Or throw some other exception ?

Are the cases that you ran into all due to allocation failing? In many areas of the libraries, the JNI code throws OOME when a native allocation fails (which can be confusing as it's not Java heap but there isn't another error to throw).

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2326826055

From bpb at openjdk.org  Tue Sep  3 15:44:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 15:44:20 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <s6R98Hq5bTpOO3X0N51spAxPMqxK8bMug9a9aA4GAsI=.599c8792-35fb-4fd3-96d1-9b16ec1cb5b4@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
 <s6R98Hq5bTpOO3X0N51spAxPMqxK8bMug9a9aA4GAsI=.599c8792-35fb-4fd3-96d1-9b16ec1cb5b4@github.com>
Message-ID: <SWHU3fPNkGrfn9EwxoZGWnUK653HGHdKMy-YXJ7e0Hk=.b2214db7-4e66-4f79-a6c7-00df58a66f23@github.com>

On Mon, 2 Sep 2024 09:06:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you planning to add a test for this?

Links can't be created without elevated permissions so I need to investigate how to do this. I think it's already done in some other tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/20801#issuecomment-2326849454

From mbaesken at openjdk.org  Tue Sep  3 15:45:21 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Sep 2024 15:45:21 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <b6ml3x63WsOVT1NOE6xYVHSo1wsPGhc5wVBdeyfsvLI=.8f157219-960a-406c-900b-9753ef6e047f@github.com>

On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

I looked into the failures we observed on macOS in the last few months and they all look similar 

test PermissionTest.allProcessesWithPermission(): failure
java.lang.RuntimeException: Cannot allocate memory
	at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
	at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
	at java.base/java.lang.ProcessHandle.allProcesses(ProcessHandle.java:199)
	at PermissionTest.allProcessesWithPermission(PermissionTest.java:78)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1583)

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2326851400

From mcimadamore at openjdk.org  Tue Sep  3 15:47:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Sep 2024 15:47:23 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <RKgJNkD0ltxgiJkiGuEVTibPU9t2Cp2coVVK45oTfnI=.f04b37fa-16ff-4633-b66e-2c9938687fc3@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <RKgJNkD0ltxgiJkiGuEVTibPU9t2Cp2coVVK45oTfnI=.f04b37fa-16ff-4633-b66e-2c9938687fc3@github.com>
Message-ID: <p2-LbQhXLCraDmx7rcvk2jWpmfb0rmo-uOpcYTeJsck=.039ab5e5-2116-4bfd-80ac-d15df5765881@github.com>

On Tue, 3 Sep 2024 11:51:57 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
>> 
>> Here is what it looks like for Windows x64:
>> 
>> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
>> 
>> Here is another chart for Linux a64:
>> 
>> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
>> 
>> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
>> 
>> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
>> 
>> 
>> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
>> 
>> 
>> This could be added in a separate PR.
>> 
>> This PR has been tested with tier1-3 and passed.
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 642:
> 
>> 640:             // 0...0X00
>> 641:             if (remaining >= 4) {
>> 642:                 final int v = SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(),src.unsafeGetOffset() + srcOffset + offset);
> 
> src.sessionImpl() worth being hoisted out once? It's a minor thing eh -same for `dst` and base/offsets

tried that - and it's mostly a wash. For `unsafeGetBase` some care is required - that method contains a cast to the sharp array type that is backing the segment (if the segment is on-heap). This cast is crucial to inform the `Unsafe` intrinsics on the type of the array being operated on. If `Unsafe` doesn't know that type it falls back to a slower intrinsics. So better to keep that where it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1742294091

From swen at openjdk.org  Tue Sep  3 15:49:23 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 15:49:23 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v16]
In-Reply-To: <1rh1WHwR2rKyQDCZW-Wr8dbT76050jjj3SKB9y48P_M=.ff253b06-7ba5-4f0c-944c-1d272993103e@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <1rh1WHwR2rKyQDCZW-Wr8dbT76050jjj3SKB9y48P_M=.ff253b06-7ba5-4f0c-944c-1d272993103e@github.com>
Message-ID: <khXpusjtcLrju2eM5wLonK4JdiyzCDaCCmInyMoSqik=.526d403f-5ea0-452a-a95e-1b97b8f2f40c@github.com>

On Tue, 3 Sep 2024 15:24:02 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - suggestion from @cl4es
>  - Revert "countGreaterThanZero -> CountNonNegatives"
>    
>    This reverts commit 431f55b46daf86fe9f2e24a2587eba8f65d847ff.

Tests show that in intermediate mode and C1, the performance of `utf8_3_bytes` and `emoji` charType has regressed

## 1. -Xint

### 1.1 Script

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

# baseline
git checkout 5d2e88fd9d808ec636b3dc7eb3e642ee864b1655
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint"

# current
git checkout c0e425cd5d711d225d98ed3cd966f4a96caea7ab
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint"


### 1.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt        Score       Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  1512116.497 ?  5557.804  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1583141.289 ?  4445.117  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  2199600.958 ? 12867.974  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  2273588.004 ?  6239.290  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt        Score       Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9   179355.324 ?   570.346  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9   222915.457 ?   521.956  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  3090322.657 ?  7896.473  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  3142324.984 ? 10690.461  ns/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 1512116.497 | 179355.324 | 743.08% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 1583141.289 | 222915.457 | 610.20% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 2199600.958 | 3090322.657 | -28.82% |
| Utf8EntryWriteTo.writeTo | emoji | 2273588.004 | 3142324.984 | -27.65% |


## 2. TieredStopAtLevel=1

### 2.1 Script

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

# baseline
git checkout 5d2e88fd9d808ec636b3dc7eb3e642ee864b1655
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout c0e425cd5d711d225d98ed3cd966f4a96caea7ab
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"



### 2.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  23465.291 ? 136.422  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  24892.661 ?  90.412  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  24555.321 ?  96.907  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  25322.357 ? 145.033  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9   9309.663 ? 122.261  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  10037.304 ?  61.700  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  31145.324 ? 168.506  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  31804.202 ?  66.719  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 23465.291 | 9309.663 | 152.05% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 24892.661 | 10037.304 | 148.00% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 24555.321 | 31145.324 | -21.16% |
| Utf8EntryWriteTo.writeTo | emoji | 25322.357 | 31804.202 | -20.38% |



## 3. Non-JVM Options

### 3.1 Script

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

# baseline
git checkout 5d2e88fd9d808ec636b3dc7eb3e642ee864b1655
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"

# current
git checkout c0e425cd5d711d225d98ed3cd966f4a96caea7ab
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"


### 3.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  15179.059 ? 152.360  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  16189.050 ?  70.459  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  15974.934 ?  61.737  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  16549.691 ? 119.606  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9   4243.038 ?  86.923  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9   5050.839 ?  24.070  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  13142.966 ? 164.620  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  13483.680 ? 244.955  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 15179.059 | 4243.038 | 257.74% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 16189.050 | 5050.839 | 220.52% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 15974.934 | 13142.966 | 21.55% |
| Utf8EntryWriteTo.writeTo | emoji | 16549.691 | 13483.680 | 22.74% |

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2326859712

From duke at openjdk.org  Tue Sep  3 15:51:24 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 3 Sep 2024 15:51:24 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
Message-ID: <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>

On Tue, 3 Sep 2024 14:03:16 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> It would be nice to see some benchmarks where it gives performance benefits.

@kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visibles...

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2326865295

From stuefe at openjdk.org  Tue Sep  3 15:53:27 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 3 Sep 2024 15:53:27 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
 <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
Message-ID: <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>

On Tue, 27 Aug 2024 15:38:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>> 
>> MethodData does a lot of deallocations from metaspace because it's allocated racily.  It might be using Metaspace wrong.
>
>> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>> 
>> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.
> 
> I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.

> @tstuefe Do you have more comments on this PR?

Sorry, I was swamped the past days. I'll take a look tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2326867932

From mcimadamore at openjdk.org  Tue Sep  3 15:54:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Sep 2024 15:54:21 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <RlALNVUs42QhIF-FiVTHy4DTpzvURLRumwTzQ2wh4bI=.c7f522de-edf4-46bc-b57a-7cf7a37bae81@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <r4r9kks7dGsAoLB1TnFiD-4AflY65_GiKMUHRIzdlKU=.e77a0457-a909-4be2-a561-b602160513d2@github.com>
 <RlALNVUs42QhIF-FiVTHy4DTpzvURLRumwTzQ2wh4bI=.c7f522de-edf4-46bc-b57a-7cf7a37bae81@github.com>
Message-ID: <ql6fKptuo8JlsRept2Dx-ue4ew-Vd_AGW39QML-YS_A=.23b787ee-4942-4208-a184-b6f76fc65f19@github.com>

On Thu, 8 Aug 2024 12:06:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I guess that upcalls are less performance critical

Think of something like `qsort`, or OpenGL calling the "repaint" function, or, with something like `jextract` , calling the clang cursor visitor. While using upcalls might be rare, the kind of use cases where you need upcalls typically fall into the bucket where the same upcall is used a gazillion time within a certain downcall. Then, it becomes performance critical.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2326871347

From alanb at openjdk.org  Tue Sep  3 15:59:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 15:59:22 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <SWHU3fPNkGrfn9EwxoZGWnUK653HGHdKMy-YXJ7e0Hk=.b2214db7-4e66-4f79-a6c7-00df58a66f23@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
 <s6R98Hq5bTpOO3X0N51spAxPMqxK8bMug9a9aA4GAsI=.599c8792-35fb-4fd3-96d1-9b16ec1cb5b4@github.com>
 <SWHU3fPNkGrfn9EwxoZGWnUK653HGHdKMy-YXJ7e0Hk=.b2214db7-4e66-4f79-a6c7-00df58a66f23@github.com>
Message-ID: <xX86Gr4i1BLb3V-j4aqA2Sd0Elnho_VzEOO617dFqg4=.6fb2422f-91de-4545-a8d4-a9e21d44fc34@github.com>

On Tue, 3 Sep 2024 15:41:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Links can't be created without elevated permissions so I need to investigate how to do this. I think it's already done in some other tests.

Can you check the tests in java/nio/file. I think they may skip if Files.createSymbolicLink fails, which it might do some Windows test machines but not others.

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

PR Comment: https://git.openjdk.org/jdk/pull/20801#issuecomment-2326881763

From bpb at openjdk.org  Tue Sep  3 16:03:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 16:03:19 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
Message-ID: <6XDQ9zwsHkz6-5fn_a7RFUTKMxgAS-v5I9LU4QttJ0s=.69966744-9129-400d-958d-c1c48b03ea47@github.com>

On Fri, 30 Aug 2024 21:39:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8003887: Free value allocated in and returned by getFinalPath()

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 494:

> 492:         }
> 493:         String canonicalPath = canonicalize0(path);
> 494:         return getFinalPath(canonicalPath);

This needs to be changed to ignore any error in `getFinalPath` and return `canonicalPath` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1742319112

From rgiulietti at openjdk.org  Tue Sep  3 16:07:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 16:07:23 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
 <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
Message-ID: <FC5hX_dCJyqW1JitRGPqItSEKIYPZn8mVFjVZ4hUTHU=.72b70706-169a-41e3-95ea-3307747c0f5b@github.com>

On Tue, 3 Sep 2024 15:49:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> It would be nice to see some benchmarks where it gives performance benefits.
>
>> It would be nice to see some benchmarks where it gives performance benefits.
> 
> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visibles...

@fabioromano1 The `MutableBigIntegersLeftShift` benchmark class in this PR does not work as written.
While the schema with `MutableBigIntegerBox` to get access to package-private methods/fields in package-private types works for unit tests, it does not for benchmarks.

I suggest you show evidence of better performance by restructuring the benchmarks to target public API points that indirectly make use of `MutableBigInteger::leftShift`, for example `BigInteger` square root, as you point out above.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2326897259

From bpb at openjdk.org  Tue Sep  3 16:07:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 16:07:24 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <xX86Gr4i1BLb3V-j4aqA2Sd0Elnho_VzEOO617dFqg4=.6fb2422f-91de-4545-a8d4-a9e21d44fc34@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
 <s6R98Hq5bTpOO3X0N51spAxPMqxK8bMug9a9aA4GAsI=.599c8792-35fb-4fd3-96d1-9b16ec1cb5b4@github.com>
 <SWHU3fPNkGrfn9EwxoZGWnUK653HGHdKMy-YXJ7e0Hk=.b2214db7-4e66-4f79-a6c7-00df58a66f23@github.com>
 <xX86Gr4i1BLb3V-j4aqA2Sd0Elnho_VzEOO617dFqg4=.6fb2422f-91de-4545-a8d4-a9e21d44fc34@github.com>
Message-ID: <QlohUXx5-W7vgd_zC9tQlKvFIHn7fhlzpsRAgGJmwI4=.8ad6fbd6-d404-46b5-8550-c3b8e0c39de8@github.com>

On Tue, 3 Sep 2024 15:56:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you check the tests in java/nio/file. I think they may skip if Files.createSymbolicLink fails, which it might do some Windows test machines but not others.

>From `Links.java`:

        // Check if sym links are supported
        try {       
            Files.createSymbolicLink(link, Paths.get("foo"));
            Files.delete(link);
        } catch (UnsupportedOperationException x) {
            // sym links not supported
            return;
        } catch (IOException x) {
            // probably insufficient privileges to create sym links (Windows)
            return;
        }

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

PR Comment: https://git.openjdk.org/jdk/pull/20801#issuecomment-2326897717

From sgehwolf at openjdk.org  Tue Sep  3 16:08:20 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Sep 2024 16:08:20 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v5]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <j_69ALYRS9hok5rOezR14V6LgZiT7niLq76UQyMq75E=.1e21f335-2b8c-40b1-9441-943182ab9423@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 proposed 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 89 additional commits since the last revision:

 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - 8339419: [s390x] Problemlist compiler/c2/irTests/TestIfMinMax.java
   
   Reviewed-by: thartmann
 - 8338916: Build warnings about overriding recipe for jvm-ldflags.txt
   
   Reviewed-by: jwaters, erikj
 - 8339336: Fix build system whitespace to adhere to coding conventions
   
   Reviewed-by: erikj
 - 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc)
   
   Reviewed-by: asotona
 - 8338740: java/net/httpclient/HttpsTunnelAuthTest.java fails with java.io.IOException: HTTP/1.1 header parser received no bytes
   
   Reviewed-by: djelinski, jpai
 - 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in linux-aarch64
   
   Reviewed-by: alanb
 - 8339401: Optimize ClassFile load and store instructions
   
   Reviewed-by: liach, redestad
 - 8339364: AIX build fails: various unused variable and function warnings
   
   Reviewed-by: mdoerr, clanger, jwaters
 - ... and 79 more: https://git.openjdk.org/jdk/compare/e4f2f439...7beccf23

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20280/files
  - new: https://git.openjdk.org/jdk/pull/20280/files/2d918ca4..7beccf23

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

  Stats: 10214 lines in 362 files changed: 6051 ins; 1713 del; 2450 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 sgehwolf at openjdk.org  Tue Sep  3 16:09:01 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Sep 2024 16:09:01 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v8]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <ma54-G4kI4bEvpkWoLi_ZOVGlk8n5uIdM1eVlkgZpKc=.17c226ee-d848-4b7e-ac31-ab8ca5973d69@github.com>

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
> - [x] GHA

Severin Gehwolf 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 15 additional commits since the last revision:

 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Fix comment of WB::host_cpus()
 - Handle non-root + CGv2
 - Add nested hierarchy to test framework
 - Revert "Add root check for SystemdMemoryAwarenessTest.java"
   
   This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
 - Add root check for SystemdMemoryAwarenessTest.java
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Add Whitebox check for host cpu
 - ... and 5 more: https://git.openjdk.org/jdk/compare/fc4604c0...cf49a96e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19530/files
  - new: https://git.openjdk.org/jdk/pull/19530/files/a98fd7d6..cf49a96e

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

  Stats: 10055 lines in 354 files changed: 6004 ins; 1681 del; 2370 mod
  Patch: https://git.openjdk.org/jdk/pull/19530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530

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

From sgehwolf at openjdk.org  Tue Sep  3 16:10:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Sep 2024 16:10:57 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v36]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <0EvV9kxXGl1wYfhaxqwiUs7rImD9AvXIi-o4Rnq20t8=.67c5f7d9-2890-4c5b-8368-20252562bceb@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 141 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - Enable GenerateJLIClassesPluginTest.java test
 - Enable JLinkReproducibleTest.java for linkable JDK images
 - Remove restriction on directory based modules
   
   Enable the following tests:
   - JLink100Modules.java
   - JLinkDedupTestBatchSizeOne.java
 - Comment fix in JRTArchive. Long line in JlinkTask
 - ... and 131 more: https://git.openjdk.org/jdk/compare/0d593cd1...ec68b0a8

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

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=35
  Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From mdoerr at openjdk.org  Tue Sep  3 16:14:23 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Sep 2024 16:14:23 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <pN_l9q8337056Lm7ud_nUkpOW1UlZJrRVhYqf7TP7gI=.4f78a6e5-71ef-406b-99b2-5392b35ca259@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4598:

> 4596:     address start = __ pc();
> 4597: 
> 4598:     __ resolve_global_jobject(R3_ARG1, R22_tmp2, R23_tmp3, MacroAssembler::PRESERVATION_FRAME_LR_GP_FP_REGS); // kills R31

The comment "// kills R31" is not true. Please remove it. Can you also improve the indentation in the succeeding lines, please? Otherwise, the PPC64 code looks good and the test/jdk/java/foreign tests are passing (also with ZGC).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1742333288

From duke at openjdk.org  Tue Sep  3 16:19:47 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 3 Sep 2024 16:19:47 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations
Message-ID: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>

Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing.

Tested using `StackMapsTest`.

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

Commit messages:
 - 8339492: StackMapDecoder::writeFrames makes lots of allocations

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

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

From swen at openjdk.org  Tue Sep  3 16:27:58 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 16:27:58 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  optimize for utf16

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/c0e425cd..059bece2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=15-16

  Stats: 194 lines in 6 files changed: 89 ins; 90 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

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

From skuksenko at openjdk.org  Tue Sep  3 16:31:18 2024
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Tue, 3 Sep 2024 16:31:18 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
 <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
Message-ID: <Wo0s8NU66pV_TyPvz3lEQ0JOGf1CnYkOG4Vm9OhK-y0=.d6156ac5-0e85-43bb-a270-e45af3c8c154@github.com>

On Tue, 3 Sep 2024 15:49:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

> > It would be nice to see some benchmarks where it gives performance benefits.
> 
> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visible...

"maybe"????
So, you don't have proof that this PR gives any performance benefits.
I don't think we have to make an optimization for the sake of optimizations.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2326955552

From liach at openjdk.org  Tue Sep  3 16:38:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 16:38:18 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations
In-Reply-To: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
Message-ID: <yPCL5RFjudJgoZ6bksT-3Pxv-jKKl17d2J8R9upGblU=.9928fa1a-a4e3-45a0-978d-0c602ac281eb@github.com>

On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing.
> 
> Tested using `StackMapsTest`.

Since users supply stack maps, they probably should ensure there's no bci overlap, and we can probably just fail-fast if they do supply duplicate entries.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2326967359

From duke at openjdk.org  Tue Sep  3 16:53:19 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 3 Sep 2024 16:53:19 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <Wo0s8NU66pV_TyPvz3lEQ0JOGf1CnYkOG4Vm9OhK-y0=.d6156ac5-0e85-43bb-a270-e45af3c8c154@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
 <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
 <Wo0s8NU66pV_TyPvz3lEQ0JOGf1CnYkOG4Vm9OhK-y0=.d6156ac5-0e85-43bb-a270-e45af3c8c154@github.com>
Message-ID: <9idRX4b22kj-n7LiVJnOsl64iEYsLLK4KIKBj6cMhSg=.c4924ce5-a054-42dc-a54e-9b9953f75690@github.com>

On Tue, 3 Sep 2024 16:29:10 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

>>> It would be nice to see some benchmarks where it gives performance benefits.
>> 
>> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visibles...
>
>> > It would be nice to see some benchmarks where it gives performance benefits.
>> 
>> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visible...
> 
> "maybe"????
> So, you don't have proof that this PR gives any performance benefits.
> I don't think we have to make an optimization for the sake of optimizations.

@kuksenko It's not only for the sake of optimization, but to make the code more clear and consistent with the implementation of `BigInteger.shiftLeft()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2326999188

From skuksenko at openjdk.org  Tue Sep  3 17:00:21 2024
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Tue, 3 Sep 2024 17:00:21 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
Message-ID: <J5vEEngVIMKJp1r1PZuFfRCbOULuUPs_4T--xeJj8fo=.291e2f11-2b1f-47dc-8aa8-6b613a3cf62d@github.com>

On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Code more clear
>  - Tests changes
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Removed trailing whitespace
>  - MutableBigInteger.leftShift(int) optimization

Clear code is essential, but it wasn't mentioned till this moment. Maybe that should be a key point.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2327009970

From rgiulietti at openjdk.org  Tue Sep  3 17:00:21 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 17:00:21 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
Message-ID: <wX9TZobj1ewVMgPPdwng-FSZfDC32xhBSsTuaqw4_qY=.7be30e4f-3107-489c-a911-7c1ffdb67bc4@github.com>

On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Code more clear
>  - Tests changes
>  - Merge branch 'openjdk:master' into patchLeftShift
>  - Removed trailing whitespace
>  - MutableBigInteger.leftShift(int) optimization

I ran the benchmark `BigIntegerSquareRoot`.

Compared to the results in the [current code](https://github.com/openjdk/jdk/pull/19710#issuecomment-2261214678), there are no significant improvements with the code in this PR.


Benchmark                        Mode  Cnt      Score     Error  Units
BigIntegerSquareRoot.testSqrtL   avgt   15   2717.091 ?  25.832  ns/op
BigIntegerSquareRoot.testSqrtM   avgt   15    741.335 ?  14.198  ns/op
BigIntegerSquareRoot.testSqrtS   avgt   15    202.612 ?   4.015  ns/op
BigIntegerSquareRoot.testSqrtXL  avgt   15  21090.732 ? 367.495  ns/op
BigIntegerSquareRoot.testSqrtXS  avgt   15      4.776 ?   0.104  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2327011588

From duke at openjdk.org  Tue Sep  3 17:03:18 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 3 Sep 2024 17:03:18 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations
In-Reply-To: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
Message-ID: <e8dPAJSdKDTbu9xQaFAA5qAHiUutLPgWZL0T5LKmvTQ=.3f6c071a-bbd8-4cec-941d-da2cd55295ea@github.com>

On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing.
> 
> Tested using `StackMapsTest`.

The previous code did not verify lack of bci overlap AFAICT, it just picked one; do I need to update the bug description or open a new one to add that?

That said, if we guarantee there's no overlap (fail fast) then we only have to loop over the array once, which is better still.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2327017308

From duke at openjdk.org  Tue Sep  3 17:18:20 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 3 Sep 2024 17:18:20 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <p2-LbQhXLCraDmx7rcvk2jWpmfb0rmo-uOpcYTeJsck=.039ab5e5-2116-4bfd-80ac-d15df5765881@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <RKgJNkD0ltxgiJkiGuEVTibPU9t2Cp2coVVK45oTfnI=.f04b37fa-16ff-4633-b66e-2c9938687fc3@github.com>
 <p2-LbQhXLCraDmx7rcvk2jWpmfb0rmo-uOpcYTeJsck=.039ab5e5-2116-4bfd-80ac-d15df5765881@github.com>
Message-ID: <IcurqQiMuy2yBKwiVeON1AdjAZkgj1l0PF8scGpcho4=.c91711c3-a2a2-47a2-a25a-7f3d3bce7eef@github.com>

On Tue, 3 Sep 2024 15:44:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 642:
>> 
>>> 640:             // 0...0X00
>>> 641:             if (remaining >= 4) {
>>> 642:                 final int v = SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(),src.unsafeGetOffset() + srcOffset + offset);
>> 
>> src.sessionImpl() worth being hoisted out once? It's a minor thing eh -same for `dst` and base/offsets
>
> tried that - and it's mostly a wash. For `unsafeGetBase` some care is required - that method contains a cast to the sharp array type that is backing the segment (if the segment is on-heap). This cast is crucial to inform the `Unsafe` intrinsics on the type of the array being operated on. If `Unsafe` doesn't know that type it falls back to a slower intrinsics. So better to keep that where it is.

thanks for the info . didn't knew about it! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1742413680

From liach at openjdk.org  Tue Sep  3 17:24:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 17:24:18 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations
In-Reply-To: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
Message-ID: <AHLp8WL2NMCv1YWriNJhnK4hOpOASeZt1dBYmYk-sME=.96f729ac-4156-45f1-ac81-4d7a2f510777@github.com>

On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing.
> 
> Tested using `StackMapsTest`.

I think you can add that to your description; it's clearly an oversight from the previous implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2327053980

From duke at openjdk.org  Tue Sep  3 17:33:37 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 3 Sep 2024 17:33:37 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
Message-ID: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>

> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
> 
> Tested using `StackMapsTest`.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback: reject duplicate stack map entries

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20841/files
  - new: https://git.openjdk.org/jdk/pull/20841/files/54b16010..04436b35

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

  Stats: 20 lines in 1 file changed: 3 ins; 14 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20841/head:pull/20841

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

From naoto at openjdk.org  Tue Sep  3 17:35:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Sep 2024 17:35:24 GMT
Subject: RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
Message-ID: <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>

On Tue, 27 Aug 2024 23:49:50 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 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>

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

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

From liach at openjdk.org  Tue Sep  3 18:08:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 18:08:19 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <2yJVkvYJh4XC6hpSOviNIP2ebN9ADLFmIBlMJFMi2AM=.1aa96bae-2b0e-4764-9c28-b16da229efe8@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>> 
>> Tested using `StackMapsTest`.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20841#pullrequestreview-2278125119

From erikj at openjdk.org  Tue Sep  3 18:12:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 3 Sep 2024 18:12:22 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <s3w0tA5ZwPTEux_ApC8BgGMObt-HQ9VJzvaC-IIj6CA=.e1e766d9-dc58-434b-8ce9-c6beedb974b4@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

I tried to take this for a spin on my m1 mac laptop. I ran configure and then `make static-jdk-image`. The build failed with the following:


chmod: /Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib: No such file or directory
ModuleWrapper.gmk:81: recipe for target '/Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib' failed
make[3]: *** [/Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib] Error 1
make[3]: *** Waiting for unfinished jobs....
make/Main.gmk:191: recipe for target 'java.base-libs' failed
make[2]: *** [java.base-libs] Error 2


I'm guessing this would work if I built the regular image first, or at least at the same time.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2327132241

From bpb at openjdk.org  Tue Sep  3 18:45:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 18:45:36 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v3]
In-Reply-To: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
Message-ID: <R405IztURCIZawYIMJ_I3MzvQes1g-7O-bxD58dThGc=.ad0b2fe1-f518-4f0f-9a00-6c660b4f5ec2@github.com>

> Return the final path derived from the string returned by `canonicalize0()`.

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

  8003887: If getFinalPath() fails, return the string returned by canonicalize0()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20801/files
  - new: https://git.openjdk.org/jdk/pull/20801/files/1cc1855b..2d6423b3

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

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

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

From duke at openjdk.org  Tue Sep  3 19:51:22 2024
From: duke at openjdk.org (duke)
Date: Tue, 3 Sep 2024 19:51:22 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <Wr3uBzae4wWqTMYw7gOzNDKmeAJd-Hzc_4UGcNrvXN4=.59ecc8c4-1e43-4daf-a2d0-bdb47e170b67@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>> 
>> Tested using `StackMapsTest`.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

@dmlloyd 
Your change (at version 04436b35d25386b5d7bf849ebd0983942d71e9c6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2327308823

From ihse at openjdk.org  Tue Sep  3 19:53:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Sep 2024 19:53:18 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <s3w0tA5ZwPTEux_ApC8BgGMObt-HQ9VJzvaC-IIj6CA=.e1e766d9-dc58-434b-8ce9-c6beedb974b4@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <s3w0tA5ZwPTEux_ApC8BgGMObt-HQ9VJzvaC-IIj6CA=.e1e766d9-dc58-434b-8ce9-c6beedb974b4@github.com>
Message-ID: <1nXZ6wL05zwQD3alCwKAo7P0XbkXkJbX_p5TFTXobvI=.d119ebf5-f5b0-495b-a16b-259110b13357@github.com>

On Tue, 3 Sep 2024 18:10:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm guessing this would work if I built the regular image first, or at least at the same time.

No, I don't think that should matter. `static-jdk-image` depends on `exploded-image`, and the files in your error message resides in `jdk`, not `images/jdk`. I have never seen this problem before. I'm not even sure why or when we try to chmod libjsig?

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2327308045

From ihse at openjdk.org  Tue Sep  3 19:53:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Sep 2024 19:53:19 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <B16wN8KTxTitqlKgNK8zWwhiC79xxRNF63JhvFLG42U=.61a51fb2-280f-486b-9013-aa73986bf9bf@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

I wonder if it is related to JDK-8336498?

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2327311982

From erikj at openjdk.org  Tue Sep  3 20:01:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 3 Sep 2024 20:01:21 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <FQ5Ecut4VNYYHMBRZhCcVejcHrInMe7vDkyNIPZkprA=.aa9111b7-e3e3-4f4a-9031-d1fb5b9f6ffb@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

make/ModuleWrapper.gmk line 59:

> 57:   endif
> 58: endif
> 59: 

This part looks a bit convoluted. It would be nice with a comment explaining what it does, where `$($(MODULE)_JDK_LIBS)` is coming from and what consumes the module-libs.txt.

make/StaticLibs.gmk line 171:

> 169: 
> 170: $(eval $(call SetupCopyFiles, copy-static-launcher, \
> 171:     SRC := $(dir $(JAVA_LAUNCHER)), \

If only copying a single file, this becomes the default value for SRC, so no need to specify it.

make/common/JdkNativeCompilation.gmk line 310:

> 308:       $$(MODULE)_JDK_LIBS += $$($1_NAME)
> 309:     endif
> 310:   endif

Same, here as in ModuleWrapper.gmk, I think we need a comment explaining how this is consumed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1742601500
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1742500522
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1742605313

From liach at openjdk.org  Tue Sep  3 20:02:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 20:02:19 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <G0G5GBtx_H3pZAXhzhjQ3oyqLBkiKnLJt-rILtneqSc=.4ed93882-b64d-442b-a102-a1e92ff6ce25@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>> 
>> Tested using `StackMapsTest`.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

Please wait a few more hours so other reviewers like @asotona can have a chance to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2327325328

From cjplummer at openjdk.org  Tue Sep  3 20:52:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Sep 2024 20:52:21 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v3]
In-Reply-To: <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>
Message-ID: <dUgbyGe0nAaNt-aUZkpFBREIyTm78Fa_K4OciaS4oRg=.8895c987-e22b-47b2-9c99-f7f6d0df69c0@github.com>

On Tue, 3 Sep 2024 03:00:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of a new method added to the JNI specification.
>> 
>> From the CSR request:
>> 
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
>> 
>> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
>> 
>> Solution
>> 
>> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
>> 
>> ---
>> 
>> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
>> 
>> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
>> 
>> Testing:
>>  - new test added
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The JNI version update was incompete

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20784#pullrequestreview-2278475330

From bpb at openjdk.org  Tue Sep  3 21:37:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 21:37:19 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <6XDQ9zwsHkz6-5fn_a7RFUTKMxgAS-v5I9LU4QttJ0s=.69966744-9129-400d-958d-c1c48b03ea47@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>
 <6XDQ9zwsHkz6-5fn_a7RFUTKMxgAS-v5I9LU4QttJ0s=.69966744-9129-400d-958d-c1c48b03ea47@github.com>
Message-ID: <-aikWZVIA9La3J4ptI9FPOR-5CqQr8RGDg9UcM2Fdp8=.c6f2bf7b-739d-457a-a1f1-0e4dce860bb3@github.com>

On Tue, 3 Sep 2024 16:00:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8003887: Free value allocated in and returned by getFinalPath()
>
> src/java.base/windows/classes/java/io/WinNTFileSystem.java line 494:
> 
>> 492:         }
>> 493:         String canonicalPath = canonicalize0(path);
>> 494:         return getFinalPath(canonicalPath);
> 
> This needs to be changed to ignore any error in `getFinalPath` and return `canonicalPath` instead.

So changed in 2d6423b.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1742720149

From bpb at openjdk.org  Tue Sep  3 21:50:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 21:50:32 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v4]
In-Reply-To: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
Message-ID: <CK0vFuzSbT4wE_mj8yuW9n9YEqJX19YgEI3De-cZwC0=.9cdda155-207c-43db-8cbc-3702b03c1506@github.com>

> Return the final path derived from the string returned by `canonicalize0()`.

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

  8003887: Test getCanonicalPath when the path contains links

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20801/files
  - new: https://git.openjdk.org/jdk/pull/20801/files/2d6423b3..44bed9ff

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

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

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

From bpb at openjdk.org  Tue Sep  3 21:50:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Sep 2024 21:50:32 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v3]
In-Reply-To: <R405IztURCIZawYIMJ_I3MzvQes1g-7O-bxD58dThGc=.ad0b2fe1-f518-4f0f-9a00-6c660b4f5ec2@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <R405IztURCIZawYIMJ_I3MzvQes1g-7O-bxD58dThGc=.ad0b2fe1-f518-4f0f-9a00-6c660b4f5ec2@github.com>
Message-ID: <k1QBWyKoc9PTSuhl0jhRi_9kz9DyoP2Ljctm3w8wHcM=.a204cb86-64be-4961-b816-aa209f66f4ef@github.com>

On Tue, 3 Sep 2024 18:45:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8003887: If getFinalPath() fails, return the string returned by canonicalize0()

With respect to the test update in 44bed9f, on Windows with link creation privilege, the three new sub-tests fail without the proposed patch applied, but succeed with it applied. On Windows without link creation privilege, the three new sub-tests simply return. On Unix, the new sub-tests pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/20801#issuecomment-2327498955

From dholmes at openjdk.org  Tue Sep  3 21:57:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Sep 2024 21:57:19 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v3]
In-Reply-To: <dUgbyGe0nAaNt-aUZkpFBREIyTm78Fa_K4OciaS4oRg=.8895c987-e22b-47b2-9c99-f7f6d0df69c0@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <0gGFOgqa6b1PoY1u-9WKnJ3UFeyz-w2qsipYoeqsoIA=.9beb9dd6-a875-4c83-85e0-d066077c5b96@github.com>
 <dUgbyGe0nAaNt-aUZkpFBREIyTm78Fa_K4OciaS4oRg=.8895c987-e22b-47b2-9c99-f7f6d0df69c0@github.com>
Message-ID: <EGFy4hRD1FFcofaQka5_K6cmN9HhkbJzbCB4UWKwS6Q=.20f71df9-e492-4e78-beb8-54c7981aecac@github.com>

On Tue, 3 Sep 2024 20:50:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The JNI version update was incompete
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks @plummercj !

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

PR Comment: https://git.openjdk.org/jdk/pull/20784#issuecomment-2327507194

From sviswanathan at openjdk.org  Tue Sep  3 22:17:34 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 3 Sep 2024 22:17:34 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
Message-ID: <UFei7Jj9XCan5MUeKAKML4_ekqukMpprHBOTapA2zVM=.24bb34e2-5413-4899-bc92-dfe800726278@github.com>

On Mon, 2 Sep 2024 12:20:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolved

Thanks for considering the review comments. I have some minor follow ups.

src/hotspot/cpu/x86/assembler_x86.cpp line 8470:

> 8468: void Assembler::vpmaxud(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8469:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 8470:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_avx512bw()), "");

avx512bw check here seems wrong.

src/hotspot/cpu/x86/assembler_x86.cpp line 8479:

> 8477: void Assembler::vpmaxud(XMMRegister dst, XMMRegister nds, Address src, int vector_len) {
> 8478:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 8479:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_avx512bw()), "");

avx512bw check here seems wrong.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 945:

> 943:  } else {
> 944:    vpblendvb(dst, src2, src1, xtmp1, vlen_enc);
> 945:  }

The comment needs to move inside if and else block as the code in these blocks is reverse of each other.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6691:

> 6689:   // Res = INP1 - INP2 (non-commutative and non-associative)
> 6690:   // Res = Mask ? Zero : Res
> 6691:   evmasked_op(etype == T_INT ? Op_SubVI : Op_SubVL, etype, ktmp, dst, src1, src2, false, vlen_enc, false);

Do the comments need update here?
e.g. 6688 is setting mask bits to true for src2 <u src1 which is no_overflow
and 6690 is thus Res = mask ? (Inp1 - Inp2) : Zero

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6715:

> 6713:                                                         int vlen_enc) {
> 6714:   // Unsigned values ranges comprise of only +ve numbers, thus there exist only an upper bound saturation.
> 6715:   // overflow_mask = (SRC1 + SRC2) <u (SRC1 | SRC2)

Thanks, xtmp2 is no more used so could be removed.

src/java.base/share/classes/java/lang/Long.java line 1987:

> 1985:     public static long addSaturating(long a, long b) {
> 1986:         long res = a + b;
> 1987:         // HD 2-12 Overflow iff both arguments have the opposite sign of the result

HD -> Hacker's Delight

src/java.base/share/classes/java/lang/Long.java line 2008:

> 2006:     public static long subSaturating(long a, long b) {
> 2007:         long res = a - b;
> 2008:         // HD 2-12 Overflow iff the arguments have different signs and

HD -> Hacker's Delight

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

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2277917757
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742347879
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742348218
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742725069
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742733746
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742751114
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742452009
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742452802

From sviswanathan at openjdk.org  Tue Sep  3 22:23:21 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 3 Sep 2024 22:23:21 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <fNMV86TdmNmcWGiulFgdENCIYSTs5lv6PCKDPSNQy2Q=.1a84e138-2db0-4f30-a393-a6101f22e62a@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
 <T8PSaIWEe2ywQsBrn1BSoirmIGnIe7jBP_XSOkjWgLQ=.48b2900b-d326-47b1-a73e-f2352e73140f@github.com>
 <fNMV86TdmNmcWGiulFgdENCIYSTs5lv6PCKDPSNQy2Q=.1a84e138-2db0-4f30-a393-a6101f22e62a@github.com>
Message-ID: <Luw6rdL9wyHM_RKyKjXXyt_DUF4yduzmhCFs_px4_VY=.6883ead2-7d58-4e35-ba82-b1dabf97252e@github.com>

On Mon, 2 Sep 2024 12:17:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 10656:
>> 
>>> 10654:   match(Set dst (SaturatingSubVI src1 src2));
>>> 10655:   match(Set dst (SaturatingSubVL src1 src2));
>>> 10656:   effect(TEMP ktmp);
>> 
>> This needs TEMP dst as well.
>
> There is no use of either of the source operands after assignment to dst in the macro assembly routine.

Sorry, I meant this for another instruct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742767372

From sviswanathan at openjdk.org  Tue Sep  3 22:23:22 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 3 Sep 2024 22:23:22 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
Message-ID: <A_tYeYCbRsSRTuVsfTvw-dVKaXVkuZ6NvzUugC7rmGI=.e0d7b639-e306-4949-9116-6136c2b0ad4b@github.com>

On Mon, 2 Sep 2024 12:20:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolved

src/hotspot/cpu/x86/x86.ad line 10684:

> 10682:   match(Set dst (SaturatingSubVI src1 src2));
> 10683:   match(Set dst (SaturatingSubVL src1 src2));
> 10684:   effect(TEMP xtmp1, TEMP xtmp2);

Here we need TEMP dst in effect, the saturating_unsigned_sub_dq_avx defines and uses dst across xtmp1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742768246

From sviswanathan at openjdk.org  Tue Sep  3 22:28:20 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 3 Sep 2024 22:28:20 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <seDDAZ9Pn8pR-EIilIWYUXL28wkKiuzauvMoa-qLZd0=.c6ac4085-53a9-4651-b4ca-1d8f1e71ba7d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
 <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
 <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>
 <QfgwwVXsYjjdGR65TfJJZjAXTS81OUyP-WOvWRRmfBk=.9e3ff6c8-201e-4b0e-93a2-9de753904279@github.com>
 <agai02WarwvrKhvnB04UiBvmolhjJaMc6y8xk0xjytU=.def3d32b-7250-4a53-a4d3-679997edd22c@github.com>
 <Vv7j1ge8HBVY0I0nVq07uuSatyIwmQaqrk47grgTqJo=.2a89c118-3ed2-499e-92a5-e4fa006e32aa@github.com>
 <seDDAZ9Pn8pR-EIilIWYUXL28wkKiuzauvMoa-qLZd0=.c6ac4085-53a9-4651-b4ca-1d8f1e71ba7d@github.com>
Message-ID: <lwui6knTVa0e5RDYYxDKG2jF0iRQSYyryReiSt_wQk4=.0b2c1a06-b84e-4dff-884c-5ae50f8f9a38@github.com>

On Mon, 2 Sep 2024 12:15:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> If the aim is to reduce the number of nodes, we could merge the Op_SaturatingAddVB, Op_SaturatingAddVS, Op_SaturatingAddVI, and Op_SaturatingAddVL into one Op_SaturatingAddV. Likewise for unsigned saturating add into Op_SaturatingUnsignedAddV.
>
> Hey @sviswa7,  our concern was around value ranges of new unsigned scalar type, which as mentioned will be addressed when I support intrinsification of new core lib APIs and associated range constraining / folding optimization in a follow up patch.

Reiterating, we are not adding unsigned scalar types with this patch, we are only supporting unsigned (saturating) operations on existing signed integral types. So in my thoughts, we could avoid this change as I mentioned above, but I will leave this one to other reviewers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1742772702

From darcy at openjdk.org  Tue Sep  3 22:58:22 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Sep 2024 22:58:22 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
Message-ID: <wK4G7LUS-Gok7NQkrOLtTQ5_CKBsItY5TFFBATdnRcE=.2ea606e1-ad67-44ed-b875-3f45483a0b6c@github.com>

On Fri, 30 Aug 2024 20:26:05 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add stub initialization and extra tanh tests

test/jdk/java/lang/Math/HyperbolicTests.java line 984:

> 982:         double b1 = 0.02;
> 983:         double b2 = 5.1;
> 984:         double b3 = 55 * Math.log(2)/2; // ~19.062

Probably better to use StrictMath.log here or, better use, precompute the value as a constant and document its conceptual origin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1742790463

From liach at openjdk.org  Tue Sep  3 23:03:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 23:03:22 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc [v2]
In-Reply-To: <nIvIudehimoc0Tm2mCLMQeRCj0WpoFiK9ErqGZ2FquA=.075a8fa5-d82b-4de2-887d-eca6271fef55@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
 <nIvIudehimoc0Tm2mCLMQeRCj0WpoFiK9ErqGZ2FquA=.075a8fa5-d82b-4de2-887d-eca6271fef55@github.com>
Message-ID: <peg1zBkXoGZTC3UhljYr3RtTKpHneaPtWmE81tejxfE=.bf6ac0cc-0474-4cc0-8719-3e38c58af878@github.com>

On Tue, 27 Aug 2024 11:52:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The string concatenation of java.base module is implemented based on StringBuilder, which will result in extra object allocation and slow performance. We can solve this problem by using String.concat method and StringConcatHelper to provide concat method.
>> 
>> for example, 
>> 
>> * use "+"
>> 
>> class ClassDesc {
>>     default String displayName() {
>>         c.displayName() + "[]".repeat(depth)
>>     }
>> }
>> 
>> 
>> bytecode:
>> 
>> 106: new           #40                 // class java/lang/StringBuilder
>> 109: dup
>> 110: invokespecial #42                 // Method java/lang/StringBuilder."<init>":()V
>> 113: aload_2
>> 114: invokeinterface #195,  1          // InterfaceMethod displayName:()Ljava/lang/String;
>> 119: invokevirtual #50                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>> 122: ldc           #198                // String []
>> 124: iload_1
>> 125: invokevirtual #200                // Method java/lang/String.repeat:(I)Ljava/lang/String;
>> 128: invokevirtual #50                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>> 131: invokevirtual #53                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
>> 134: areturn
>> 
>> 
>> * use String#concat
>> 
>> c.displayName().concat("[]".repeat(depth))
>> 
>> 
>> bytecode:
>> 
>> 112: ldc           #198                // String []
>> 114: iload_1
>> 115: invokevirtual #200                // Method java/lang/String.repeat:(I)Ljava/lang/String;
>> 118: invokevirtual #86                 // Method java/lang/String.concat:(Ljava/lang/String;)Ljava/lang/String;
>
> Shaojin Wen has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - more concat
>  - Suggestions from @ExE-Boss
>  - concat Object value

Tier 1-3 tests look good.

For context, some core library developers are currently investigating if we can mark some classes and methods as used in early startup, after this problem was raised in OpenJDK committer's workshop (and encountered in the generics experiment work shown in JVMLS 2024); those methods can fail fast if they use lambdas, and we can make compiler generate regular string concat in other methods.

However, most of your changes here are on code used before string concat is ready, so this is a good improvement.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20705#pullrequestreview-2278655776
PR Comment: https://git.openjdk.org/jdk/pull/20705#issuecomment-2327592311

From swen at openjdk.org  Tue Sep  3 23:08:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 23:08:20 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
Message-ID: <uJybXDR0VpwORMl8HfUJbtGFEsDlzFpURDNOw0Eu4bc=.bb953e9b-a204-4685-be8a-1a6aa0514814@github.com>

On Tue, 3 Sep 2024 16:27:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize for utf16

5d2e88fd9d808ec636b3dc7eb3e642ee864b1655 This version has resolved the startup performance regression in non-LATIN1 scenarios, and works well in scenarios where COMPACT_STRINGS=false or UTF16 strings with mostly ASCII characters in the prefix.

## 1. This intermediate mode

### 1.1 Script

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

# baseline
git checkout 5d2e88fd9d808ec636b3dc7eb3e642ee864b1655
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint"

# current
git checkout 059bece2b1b4aac644ee5e3c3c69246bd7cf50b6
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint"


### 1.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt        Score       Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  1509448.291 ?  2654.329  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  1583379.661 ?  4149.880  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  2197701.771 ? 13988.343  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  2271586.139 ?  5295.697  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt        Score      Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9   178505.438 ? 4274.523  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9   211906.736 ? 1033.539  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  1303843.386 ? 3763.852  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  1360258.109 ? 4651.772  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 1509448.291 | 178505.438 | 745.60% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 1583379.661 | 211906.736 | 647.21% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 2197701.771 | 1303843.386 | 68.56% |
| Utf8EntryWriteTo.writeTo | emoji | 2271586.139 | 1360258.109 | 67.00% |



## 2. TieredStopAtLevel=1

### 2.1 Script

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

# baseline
git checkout 5d2e88fd9d808ec636b3dc7eb3e642ee864b1655
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"

# current
git checkout 059bece2b1b4aac644ee5e3c3c69246bd7cf50b6
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo" MICRO="VM_OPTIONS=-Xint -XX:TieredStopAtLevel=1"



### 2.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  23496.089 ? 200.645  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  24994.492 ? 221.328  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  24572.165 ?  58.997  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  25345.417 ?  65.883  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt      Score    Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9   7949.429 ? 33.514  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9   8661.021 ? 55.333  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  18511.109 ? 18.346  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  19239.642 ? 78.234  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 23496.089 | 7949.429 | 195.57% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 24994.492 | 8661.021 | 188.59% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 24572.165 | 18511.109 | 32.74% |
| Utf8EntryWriteTo.writeTo | emoji | 25345.417 | 19239.642 | 31.74% |




## 3. Non-JVM Options

### 3.1 Script

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

# baseline
git checkout 5d2e88fd9d808ec636b3dc7eb3e642ee864b1655
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"

# current
git checkout 059bece2b1b4aac644ee5e3c3c69246bd7cf50b6
make test TEST="micro:java.lang.classfile.Utf8EntryWriteTo"


### 3.2 MacBook M1 Pro Performance Numbers


-# baseline
-Benchmark                   (charType)  Mode  Cnt      Score     Error  Units
-Utf8EntryWriteTo.writeTo         ascii  avgt    9  15178.781 ?  38.239  ns/op
-Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  16335.573 ? 288.536  ns/op
-Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  16008.245 ?  47.895  ns/op
-Utf8EntryWriteTo.writeTo         emoji  avgt    9  16619.964 ? 161.419  ns/op

+# current
+Benchmark                   (charType)  Mode  Cnt     Score     Error  Units
+Utf8EntryWriteTo.writeTo         ascii  avgt    9  4200.584 ?  82.228  ns/op
+Utf8EntryWriteTo.writeTo  utf8_2_bytes  avgt    9  5019.010 ?  20.490  ns/op
+Utf8EntryWriteTo.writeTo  utf8_3_bytes  avgt    9  7811.282 ?  27.938  ns/op
+Utf8EntryWriteTo.writeTo         emoji  avgt    9  8106.677 ? 134.932  ns/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Utf8EntryWriteTo.writeTo | ascii | 15178.781 | 4200.584 | 261.35% |
| Utf8EntryWriteTo.writeTo | utf8_2_bytes | 16335.573 | 5019.010 | 225.47% |
| Utf8EntryWriteTo.writeTo | utf8_3_bytes | 16008.245 | 7811.282 | 104.94% |
| Utf8EntryWriteTo.writeTo | emoji | 16619.964 | 8106.677 | 105.02% |

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2327597330

From liach at openjdk.org  Tue Sep  3 23:22:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Sep 2024 23:22:28 GMT
Subject: RFR: 8339131: Remove rarely-used accessor methods from Opcode [v2]
In-Reply-To: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
References: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
Message-ID: <dZH1WEvjeQuT_C9IJfAaQ-UAKUp5JFm7WV99SbvYBF0=.58991538-005c-419f-98dd-1e93c0debeb9@github.com>

> In offline discussion, we agreed that current fields of `Opcode` violate data oriented design to a large extent. The attributes not generic to all opcode are removed.
> 
> Up for preliminary review; needs to be reworked for #20737.

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

 - Revert back to enum switch, fix compile error
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Fix ofArgument in loadConstant patch instead, improve specs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Clean up opcode fields

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

Changes: https://git.openjdk.org/jdk/pull/20757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20757&range=01
  Stats: 469 lines in 8 files changed: 189 ins; 77 del; 203 mod
  Patch: https://git.openjdk.org/jdk/pull/20757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20757/head:pull/20757

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

From swen at openjdk.org  Tue Sep  3 23:25:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 3 Sep 2024 23:25:37 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v5]
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <_jNTwobMIwbRjKC1MW1qQKCJzXK1Re5hpOU4z-W7DV4=.42409bae-39ec-468b-94ba-df63ce2d0f52@github.com>

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

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:

 - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
 - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
 - revert skip
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Suggestions from @cl4es
 - fix build error
 - remove BufWriter#patchInt
 - optimize BufWriterImpl#patchInt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20780/files
  - new: https://git.openjdk.org/jdk/pull/20780/files/058d8dad..e3dc3014

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

  Stats: 5709 lines in 251 files changed: 2837 ins; 1178 del; 1694 mod
  Patch: https://git.openjdk.org/jdk/pull/20780.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20780/head:pull/20780

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

From redestad at openjdk.org  Tue Sep  3 23:52:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 3 Sep 2024 23:52:19 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
Message-ID: <-faXuVgp4MfLl8Gedpw8kItIuOmdIN8cPpEbxliSBPY=.35964705-ce8d-4c63-b1ed-a4e4298d13b2@github.com>

On Tue, 3 Sep 2024 16:27:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize for utf16

This looks very promising. Good to not have to leak out `isLatin1` via the `SharedSecrets`. I'll run some extra testing overnight, and review in detail tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2327639992

From darcy at openjdk.org  Wed Sep  4 00:03:20 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Sep 2024 00:03:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
Message-ID: <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>

On Fri, 30 Aug 2024 20:26:05 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add stub initialization and extra tanh tests

test/jdk/java/lang/Math/HyperbolicTests.java line 1009:

> 1007:         for(int i = 0; i < testCases.length; i++) {
> 1008:             double testCase = testCases[i];
> 1009:             failures += testTanhWithReferenceUlpDiff(testCase, StrictMath.tanh(testCase), 2.5);

The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.

For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).

If the test is going to use randomness, then its jtreg tags should include

`@key randomness`

and it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1742826418

From swen at openjdk.org  Wed Sep  4 00:36:39 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 00:36:39 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v6]
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <XGHbduMULIcz92cf3VB-hQVn9lP-ywBemwvgI45h3zo=.91b30b91-c406-4f81-8d96-eebd92f1c7d7@github.com>

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

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

 - Eliminate redundant variables
 - buf skip

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20780/files
  - new: https://git.openjdk.org/jdk/pull/20780/files/e3dc3014..21f0a229

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

  Stats: 25 lines in 4 files changed: 12 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20780.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20780/head:pull/20780

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

From andrew at openjdk.org  Wed Sep  4 00:37:31 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 4 Sep 2024 00:37:31 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <fgXfd-S1Ew6vwNbw6O7qVz9rv_Cy24qcKgiApyHPSpE=.d481320a-ccf0-45f3-9cca-37d884915880@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
 <fgXfd-S1Ew6vwNbw6O7qVz9rv_Cy24qcKgiApyHPSpE=.d481320a-ccf0-45f3-9cca-37d884915880@github.com>
Message-ID: <rn489cI0jZTtxn0QVC6f1TYGd4NGmS3kGpS7G3jVm3s=.a57a9bbe-7319-4728-8e0f-96d43f68e1e2@github.com>

On Mon, 2 Sep 2024 16:02:31 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions
>
> I can't review, as I ported the native code changes. On that note, can you make sure I'm credited as co-author using [/contributor](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor) please? 
> 
> i.e. /contributor add @gnu-andrew
> 
> You may want to also comment on [JDK-8185896](https://bugs.openjdk.org/browse/JDK-8185896) which is about adding Zip64 tests.

> Hi @gnu-andrew, I have corrected your contributor status, thank you for the reminder.
> 
> I do not have access to comment on https://bugs.openjdk.org/browse/JDK-8185896. Can you please add a comment from me that says:
> 
> "I have added to #19678 two ZIP64 test cases: one for ZIP64 extensions added implicitly due to one of the CEN fields being too large to represent, and one for ZIP64 extensions that have been added explicitly even though no CEN field required them.
> 
> It is not complete coverage -- the "implicit" test only tests the field for the total number of entries. But the coverage they provide may be enough to warrant closing JDK-8185896.
> 
> The test cases are fast and portable back to OpenJDK 8, and do not require significant disk space, so they can be run unconditionally as part of the default `jtreg` test set."

Done. Thanks for adding the attribution.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2327687252

From swen at openjdk.org  Wed Sep  4 01:08:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 01:08:20 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <ARQNL0KIDVbswpiixcTNXV3xvtMnr9lb-dShu1-DyVI=.ac8b296a-c453-48f4-aa8a-b569751d0afe@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>> 
>> Tested using `StackMapsTest`.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

It looks good, but can you provide the codeSize before and after the change? For example, add the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to find `writeFrames` and see if this PR will change from less than 325 to greater than 325.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2327714378

From dholmes at openjdk.org  Wed Sep  4 01:34:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Sep 2024 01:34:26 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <zygRGCJzlGdAVCN6rTqBI-YsIpHL87WRLqKAgzr6yLM=.9c46f227-6bc5-4411-acb4-ff471dfe5291@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

src/hotspot/share/prims/upcallLinker.cpp line 142:

> 140:   Handle exception_h(Thread::current(), exception);
> 141:   java_lang_Throwable::print_stack_trace(exception_h, tty);
> 142:   ShouldNotReachHere();

How does `print_stack_trace` not return here?

test/jdk/java/foreign/TestUpcallStress.java line 27:

> 25:  * @test
> 26:  * @requires jdk.foreign.linker != "FALLBACK"
> 27:  * @requires os.arch == "aarch64" & os.name == "Linux"

Only for Linux-aarch64 ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1742870369
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1742871513

From jbhateja at openjdk.org  Wed Sep  4 02:00:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Sep 2024 02:00:25 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
 <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>
 <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>
Message-ID: <2nRoXBr_v8DjlG4wJlWF9OhYMmgpTUDX6VAQnvO3DCY=.596e5e39-c5ba-4d20-b5e0-aa301f7c9d76@github.com>

On Tue, 27 Aug 2024 22:23:44 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> I agree, this is all rather obscure. Ideally the same names that are used in wherever this comes from.
>> 
>> Where does the algorithm come from? What are its accuracy guarantees?
>> 
>> In addition, given the rarity of hyperbolic tangents in Java applications, do we need this?
>
> @theRealAph, this implementation is based on Intel libm math library and meets the accuracy requirements. The algorithm is provided in the comments.

@vamsi-parasa  don't hesitate in adding as much and explicit information about the original source from where the algorithm has been picked up, even though the PR explicitly mentions libm. Adding the link to source references is a good practice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1742887385

From dholmes at openjdk.org  Wed Sep  4 03:44:30 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Sep 2024 03:44:30 GMT
Subject: Integrated: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths
In-Reply-To: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
Message-ID: <js8WANccaQydP6Fnu8RQfOL9ZUInkZzrFSd8FEx8Uf8=.0a07b495-7f82-4421-bec5-aa252a20b857@github.com>

On Fri, 30 Aug 2024 02:07:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is the implementation of a new method added to the JNI specification.
> 
> From the CSR request:
> 
> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
> 
> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
> 
> Solution
> 
> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
> 
> ---
> 
> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
> 
> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
> 
> Testing:
>  - new test added
>  - tiers 1-3 sanity
> 
> Thanks

This pull request has now been integrated.

Changeset: 90f3f432
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90f3f4325772773f1dc1814c56d7326d5389e2c7
Stats:     209 lines in 9 files changed: 182 ins; 1 del; 26 mod

8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths

Reviewed-by: cjplummer, alanb

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

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

From fyang at openjdk.org  Wed Sep  4 06:17:19 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 4 Sep 2024 06:17:19 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <yL-Cf6a0eIZko_BfkudPfyGpaDP6hGCDl4sdbRxQ3jw=.37886e1b-e6d3-4abd-bde3-d988804f8f36@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 264:

> 262: 
> 263:   __ block_comment("{ load target ");
> 264:   __ movptr(j_rarg0, (intptr_t) receiver);

Hi @JornVernee , Could you please apply following small add-on change for linux-riscv64? As I witnessed build warning with GCC-13. Otherwise, builds fine and the newly-added test/jdk/java/foreign/TestUpcallStress.java is passing.


diff --git a/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp b/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp
index 5c45a679316..55160be99d0 100644
--- a/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp
+++ b/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp
@@ -261,7 +261,7 @@ address UpcallLinker::make_upcall_stub(jobject receiver, Symbol* signature,
   __ block_comment("} argument shuffle");

   __ block_comment("{ load target ");
-  __ movptr(j_rarg0, (intptr_t) receiver);
+  __ movptr(j_rarg0, (address) receiver);
   __ far_call(RuntimeAddress(StubRoutines::upcall_stub_load_target())); // loads Method* into xmethod
   __ block_comment("} load target ");

diff --git a/test/jdk/java/foreign/TestUpcallStress.java b/test/jdk/java/foreign/TestUpcallStress.java
index 3b9b1d4b207..40607746856 100644
--- a/test/jdk/java/foreign/TestUpcallStress.java
+++ b/test/jdk/java/foreign/TestUpcallStress.java
@@ -24,7 +24,7 @@
 /*
  * @test
  * @requires jdk.foreign.linker != "FALLBACK"
- * @requires os.arch == "aarch64" & os.name == "Linux"
+ * @requires (os.arch == "aarch64" | os.arch=="riscv64") & os.name == "Linux"
  * @requires os.maxMemory > 4G
  * @modules java.base/jdk.internal.foreign
  * @build NativeTestHelper CallGeneratorHelper TestUpcallBase

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743130094

From asotona at openjdk.org  Wed Sep  4 06:56:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Sep 2024 06:56:19 GMT
Subject: RFR: 8339131: Remove rarely-used accessor methods from Opcode [v2]
In-Reply-To: <dZH1WEvjeQuT_C9IJfAaQ-UAKUp5JFm7WV99SbvYBF0=.58991538-005c-419f-98dd-1e93c0debeb9@github.com>
References: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
 <dZH1WEvjeQuT_C9IJfAaQ-UAKUp5JFm7WV99SbvYBF0=.58991538-005c-419f-98dd-1e93c0debeb9@github.com>
Message-ID: <Meu6UK-XOZn9N4Lhupvv8jjeXIntEH45_11QadyYv84=.4bf039ba-4a1f-4f82-9470-a8d98ec0f002@github.com>

On Tue, 3 Sep 2024 23:22:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we agreed that current fields of `Opcode` violate data oriented design to a large extent. The attributes not generic to all opcode are removed.
>> 
>> Up for preliminary review; needs to be reworked for #20737.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Revert back to enum switch, fix compile error
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Fix ofArgument in loadConstant patch instead, improve specs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Clean up opcode fields

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20757#pullrequestreview-2279150127

From miiiinju00 at gmail.com  Wed Sep  4 07:09:31 2024
From: miiiinju00 at gmail.com (=?UTF-8?B?6rmA66+87KO8?=)
Date: Wed, 4 Sep 2024 16:09:31 +0900
Subject: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high
 contention and suggestion for fair mode in ArrayBlockingQueue and
 LinkedBlockingQueue
Message-ID: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>

Hello core-libs-dev team,

My name is Kim Minju, and I have investigated a potential issue with both
ArrayBlockingQueue and LinkedBlockingQueue implementations when handling
high contention scenarios. While I am not entirely certain whether this is
a bug or expected behavior,

I would like to share my findings and seek your input. If this is indeed an
issue, I would also like to propose a fix and work on implementing it, with
the community's guidance and support.
Problem Description:

When the queue is full, and both put() operations and item consumption
occur simultaneously, threads that have been waiting to insert elements
using notFull.await() are expected to be unblocked in a strict FIFO order.
However, in my tests, when space becomes available, both the unblocked
threads and newly arriving put() requests compete for the lock, potentially
leading to race conditions. This can result in newer threads acquiring the
lock first and inserting items before previously blocked threads, which
seems to violate FIFO order.

In ArrayBlockingQueue, while a fair mode is available, it does not seem to
fully guarantee strict FIFO order under high contention. Additionally,
LinkedBlockingQueue lacks any fair mode, which seems to exacerbate the
issue, allowing newer threads to preempt waiting threads more easily.

I am unsure if this behavior is by design or if it can be improved. I would
greatly appreciate any feedback from the community regarding whether this
is an intended behavior or a potential issue.
Steps to Reproduce:

Here is a test case that demonstrates how FIFO order can be violated when
threads blocked on put() calls are unblocked and compete with new put()
requests for lock acquisition:

import static org.junit.jupiter.api.Assertions.fail;

import java.lang.Thread.State;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.atomic.AtomicInteger;
import org.junit.jupiter.api.Test;

class BlockingQueueFIFOTest {

    @Test
    void testFIFOOrder() throws InterruptedException {
        final int QUEUE_CAPACITY = 10;
        AtomicInteger sequenceGenerator = new AtomicInteger(0);

        // Create a blocking queue with a fixed capacity
        BlockingQueue<Integer> queue = new
LinkedBlockingQueue<>(QUEUE_CAPACITY);
//        queue = new ArrayBlockingQueue<>(QUEUE_CAPACITY, true);

        // Prefill the queue to its capacity
        // This is crucial for the test as it ensures subsequent put
operations will block
        // By filling the queue first, we guarantee that following put
operations
        // will be queued in the exact order they are called (10, 11, 12, ...)
        // This setup creates a controlled environment for testing FIFO behavior
         for(int i = 0;i<QUEUE_CAPACITY;i++) {
            queue.put(sequenceGenerator.getAndIncrement());
        }

        final int PRODUCER_COUNT = 100;
        final int PRODUCER_COUNT_WHEN_CONSUMING = 1000;

        // Create multiple producer threads
        // Each thread attempts to put a single item into the already full queue
        // Since the queue is full, these put operations will block in
the order they are called
        // This configuration ensures items enter the queue's waiting
list in a predictable sequence (10, 11, 12, ...)
        // allowing us to verify if they are later consumed in the same order
        for (int i = 0; i < PRODUCER_COUNT; i++) {
            Thread thread = new Thread(() -> {
                try {
                    queue.put(sequenceGenerator.getAndIncrement());
                } catch (InterruptedException e) {
                    // ignore
                }

            });
            thread.start();
            // Wait for the producer thread to enter BLOCKED state
            // This ensures that the thread is waiting on the full queue
            while (thread.getState() == State.RUNNABLE ||
thread.getState() == State.NEW);
        }

        List<Integer> result = new ArrayList<>();

        // This simulates a real-world high-contention scenario on a full queue
        // When space becomes available, it's not just waiting threads
that compete
        // New put requests arrive simultaneously, adding to the contention
        // This tests if FIFO order is maintained under intense
pressure from both
        Thread producingWhenConsumingThread = new Thread(() -> {
            for (int i = 0; i < PRODUCER_COUNT_WHEN_CONSUMING; i++) {
                Thread thread = new Thread(() -> {
                    try {
                        queue.put(sequenceGenerator.getAndIncrement());
                    } catch (InterruptedException e) {
                        // ignore
                    }

                });
                thread.start();

                // Wait for the producer thread to enter BLOCKED state
                // This ensures that the thread is waiting on the full queue
                while (thread.getState() == State.RUNNABLE ||
thread.getState() == State.NEW);
            }
        });
        producingWhenConsumingThread.start();

        for (int i = 0; i < PRODUCER_COUNT + QUEUE_CAPACITY +
PRODUCER_COUNT_WHEN_CONSUMING ; i++) {
            Integer item = queue.take();
            result.add(item);
        }
        System.out.println("result = " + result);

        for (int i = 0; i < result.size() - 1; i++) {
            if (result.get(i) > result.get(i + 1)) {
                fail("FIFO order violated at index " + i + ": " +
result.get(i) + " > " + result.get(i + 1));
            }
        }
    }
}


Expected Behavior:

When the queue is full and multiple threads are blocked on put() operations
(using notFull.await()), these threads should be unblocked in the order
they were blocked, with newly arriving put() requests waiting until the
blocked threads have inserted their elements. The blocked threads should
have priority over new threads, and lock acquisition should respect this
order.
Actual Behavior (Observed in Testing):

Under high contention, both ArrayBlockingQueue and LinkedBlockingQueue seem
to violate FIFO order due to lock contention between threads that were
blocked on notFull.await() and new put() requests. Newly arriving threads
can sometimes preempt previously blocked threads, resulting in newer items
being inserted ahead of older ones.

Again, I am uncertain if this is an expected consequence of the current
implementation or if there is room for improvement.
Proposed Solution (If This is a Problem):

If this behavior is not intended, I propose modifying both
ArrayBlockingQueue and LinkedBlockingQueue so that if there are threads
waiting on notFull.await(), newly arriving put() requests would be forced
to wait behind the blocked threads. This could help ensure that previously
blocked threads insert their items in FIFO order, minimizing FIFO
violations due to lock contention.

Additionally, I suggest adding an option for *fair mode* in
LinkedBlockingQueue, similar to what is available in ArrayBlockingQueue.
This would further ensure that waiting threads are processed in a
predictable and fair manner, preventing newer threads from preempting
waiting threads and thus maintaining strict FIFO order.
Performance Considerations:

I understand that implementing stricter FIFO guarantees may impact overall
throughput, especially in high-contention scenarios. To address this, I
suggest making these changes configurable, allowing users to choose between
strict FIFO ordering and potentially higher throughput, depending on their
workload needs.

If the community deems this change valuable, I am willing to conduct
thorough performance testing to quantify the impact on throughput and
latency under various workloads, and I could create JMH benchmarks to
measure the performance differences between the current and proposed
implementations.
Request for Sponsorship and Feedback:

As I am not yet an Author in the OpenJDK project, I am seeking guidance and
potential sponsorship to address this issue, should it be deemed necessary.

   - I would appreciate the community's thoughts on whether this behavior
   is expected or a potential issue worth addressing.
   - If the community agrees that this is a significant issue, I welcome
   guidance on the best approach to tackle it within the current Java
   implementation.
   - I am looking for a sponsor who might be interested in supporting this
   effort. With sponsorship, I would be glad to:
      - Conduct a deeper analysis of the problem
      - Create a prototype implementation for review
      - Prepare and submit a formal patch
      - Participate in the review process and make necessary adjustments

Thank you for your time and consideration. I look forward to your feedback
and the opportunity to contribute to the improvement of Java's concurrent
collections.

Best regards,

Kim Minju

miiiinju00 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/aa51be9d/attachment.htm>

From attila at openjdk.org  Wed Sep  4 08:12:55 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Wed, 4 Sep 2024 08:12:55 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v5]
In-Reply-To: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
References: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
Message-ID: <jKzvN7v4pJl2INstuTMJgtQW1eOgiS_ZCFdSX6xxeCc=.1c5cb665-0dc1-465d-ba1e-db9de4f535df@github.com>

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

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

  Updated copyright years and added a bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17818/files
  - new: https://git.openjdk.org/jdk/pull/17818/files/a5537664..ed50c3da

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

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

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

From pminborg at openjdk.org  Wed Sep  4 08:19:21 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Sep 2024 08:19:21 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <qPOgH8bFsZzG9ru2DJKSNb9aZM3-NlQh7tb4Mr45XEg=.9f30ca99-e534-4282-a8fb-47c360468799@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <_eQBOo3xh4ggMDO8wfqrOe3ovf2dOelyPSFHRMOvkGU=.3e183b75-2e16-4f61-abf4-35e92347cd22@github.com>
 <qPOgH8bFsZzG9ru2DJKSNb9aZM3-NlQh7tb4Mr45XEg=.9f30ca99-e534-4282-a8fb-47c360468799@github.com>
Message-ID: <fudprCaNDUcC6gqgex49kCov8lL4O9_xidzwx5WVc0E=.f85114b3-e76d-4349-85e7-0d726ec651d7@github.com>

On Tue, 3 Sep 2024 15:23:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 637:
>> 
>>> 635:             for (; offset < limit; offset += 8) {
>>> 636:                 final long v = SCOPED_MEMORY_ACCESS.getLong(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcOffset + offset);
>>> 637:                 SCOPED_MEMORY_ACCESS.putLong(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstOffset + offset, v);
>> 
>> I've been digging a bit deeper on why we can get away w/o aligned access (both here and for `fill`). It turns out that, conveniently, var handles use `Unsafe::getXYZUnaligned` for plain set/get. This means that the intrinsics will deal with unaligned access accordingly, depending on the platform (either by splitting into multiple accesses, or by issuing an unaligned access on platforms that support that).
>> 
>> This means we can write "simple" code, and expect C2 to rewrite it the most optimal way. We should probably add a comment in this direction (both for `fill` and `copy`.
>
> Separately, I wonder if it would make sense to put all these "tricky" routines off to one side - e.g. `BulkSegmentSupport`, so that we don't make `AbstractMemorySegmentImpl` even bigger than it is.

Having these bulk methods in a separate class makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1743280272

From epeter at openjdk.org  Wed Sep  4 08:21:26 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 4 Sep 2024 08:21:26 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <UFei7Jj9XCan5MUeKAKML4_ekqukMpprHBOTapA2zVM=.24bb34e2-5413-4899-bc92-dfe800726278@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
 <UFei7Jj9XCan5MUeKAKML4_ekqukMpprHBOTapA2zVM=.24bb34e2-5413-4899-bc92-dfe800726278@github.com>
Message-ID: <ybu0dIUk0U6D9Wi3ighZHAAdHr2FXL6OR0MYDHoc6cI=.99a18591-f884-41a0-ac26-9c752397fe38@github.com>

On Tue, 3 Sep 2024 16:23:56 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolved
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 8470:
> 
>> 8468: void Assembler::vpmaxud(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
>> 8469:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
>> 8470:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_avx512bw()), "");
> 
> avx512bw check here seems wrong.

If this is indeed wrong, then we are missing tests, and you should add some more.

> src/hotspot/cpu/x86/assembler_x86.cpp line 8479:
> 
>> 8477: void Assembler::vpmaxud(XMMRegister dst, XMMRegister nds, Address src, int vector_len) {
>> 8478:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
>> 8479:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_avx512bw()), "");
> 
> avx512bw check here seems wrong.

If this is indeed wrong, then we are missing tests, and you should add some more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1743283892
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1743284116

From alanb at openjdk.org  Wed Sep  4 08:47:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Sep 2024 08:47:21 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v4]
In-Reply-To: <CK0vFuzSbT4wE_mj8yuW9n9YEqJX19YgEI3De-cZwC0=.9cdda155-207c-43db-8cbc-3702b03c1506@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <CK0vFuzSbT4wE_mj8yuW9n9YEqJX19YgEI3De-cZwC0=.9cdda155-207c-43db-8cbc-3702b03c1506@github.com>
Message-ID: <yV3uxBYNrAKb38t7rXgcltwfDE9cmFqzmOZumqtvIuA=.9a332106-2263-4541-b7d5-7adeda68d546@github.com>

On Tue, 3 Sep 2024 21:50:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8003887: Test getCanonicalPath when the path contains links

src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 347:

> 345: 
> 346:     if (rv == NULL && !(*env)->ExceptionCheck(env)) {
> 347:         JNU_ThrowIOExceptionWithLastError(env, "Bad pathname"); // XXX message?

That "not useful" exception message is probably okay because this is what canonicalize has always used.

test/jdk/java/io/File/GetCanonicalPath.java line 129:

> 127:     }
> 128: 
> 129:     private static Path createPath(String pathname) throws IOException {

This method creates a File, returning a Path to the file, so maybe better method name needed here.

test/jdk/java/io/File/GetCanonicalPath.java line 135:

> 133:     }
> 134: 
> 135:     private static boolean testLinks = true;

It might be clearer to replace this with supportsLinks and have the tests Assumptions.asserTrue(supportsLinks) so they will be skipped when not supported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1743316741
PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1743319200
PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1743322928

From mbaesken at openjdk.org  Wed Sep  4 09:14:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Sep 2024 09:14:20 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>

On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

The Apple sysctl manpage
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html
documents a few ENOMEM related errors so the issue is probably related to these.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2328329531

From alanb at openjdk.org  Wed Sep  4 09:32:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Sep 2024 09:32:18 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>
Message-ID: <UJ90n2n2eCJXBLr1KOC1oUs17lFaKJmO4DbbjmlJDH8=.476fcc46-111a-4333-8914-e627b2203910@github.com>

On Wed, 4 Sep 2024 09:11:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The Apple sysctl manpage https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html documents a few ENOMEM related errors so the issue is probably related to these.

In your investigations, is it the first or second call to sysctl(3) that is failing? If the second call then it makes me wonder if there needs to be a loop here as the number of processes may have increased after allocating the buffer.

(I realise this is separate to the question as to whether the children method should be allowed to throw but an ENOMEM from the second call to sysctl suggests a bug)






How intermittent is this? I'm wondering if it's a genuine ENOMEM or something more intermittent. In the networking area, the JDK has code to retry setsockopt(IP_ADD_MEMBERSHIP) due to an intermittent ENOMEM. In that case we couldn't get a handle on the conditions when it happens.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2328369278

From pminborg at openjdk.org  Wed Sep  4 09:46:35 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Sep 2024 09:46:35 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch
Message-ID: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>

This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

Commit messages:
 - Remove temp methods
 - Clean up
 - Update comment
 - Merge branch 'master' into mismatch-performance2
 - Create a separate class for segment bulk operations
 - Add Java implementation of MS::mismatch

Changes: https://git.openjdk.org/jdk/pull/20848/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339531
  Stats: 267 lines in 4 files changed: 230 ins; 34 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From mdoerr at openjdk.org  Wed Sep  4 10:03:21 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Sep 2024 10:03:21 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <lgttiVGFH9LgYzOGqlvbjJyimVAGjzMqcx56gQNS3pE=.433730d3-589a-488d-8bf0-225ff181f292@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062:

> 3060:     StubCodeMark mark(this, "StubRoutines", "upcall_stub_load_target");
> 3061:     address start = __ pc();
> 3062:     __ save_return_pc();

@offamitkumar: Is saving and restoring the return_pc needed? Isn't in preserved by load_heap_oop?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743436851

From mcimadamore at openjdk.org  Wed Sep  4 10:17:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Sep 2024 10:17:19 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <65LIOx0iXiGTw5PRS01M5_AMiWhpDrU4jd0Fl4ePHi8=.1f877f4f-47ff-4417-9993-b147f8e54de1@github.com>

On Wed, 4 Sep 2024 09:09:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 123:

> 121:     // This method is intended for 0 <= bytes < 7
> 122:     @ForceInline
> 123:     private static long mismatchSmall(AbstractMemorySegmentImpl src, long srcOffset,

Question. Isn't this:


// 0...0X00
            if (remaining >= 4) {
                if (SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset) !=
                        SCOPED_MEMORY_ACCESS.getInt(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset)) {
                    return mismatchSmall(src, srcFromOffset + offset, dst, dstFromOffset + offset, offset, 4, srcAndDstBytesDiffer);
                }
                offset += 4;
                remaining -= 4;
            }
            // 0...00X0
            if (remaining >= 2) {
                if (SCOPED_MEMORY_ACCESS.getShort(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset) !=
                        SCOPED_MEMORY_ACCESS.getShort(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset)) {
                    return mismatchSmall(src, srcFromOffset + offset, dst, dstFromOffset + offset, offset, 2, srcAndDstBytesDiffer);
                }
                offset += 2;
                remaining -= 2;
            }
            // 0...000X
            if (remaining == 1) {
                if (SCOPED_MEMORY_ACCESS.getByte(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset) !=
                        SCOPED_MEMORY_ACCESS.getByte(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset)) {
                    return offset;
                }
            }


An optimized version of "mismatchSmall" ? Can we reuse the code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1743461331

From lucy at openjdk.org  Wed Sep  4 10:21:18 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 4 Sep 2024 10:21:18 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <-sxU0d7Qe25_Pa8bBaYUGRGsNJry60YxEkXz39bXq-0=.cd560473-4e84-4d12-9f33-9f2faf53a9b5@github.com>

On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2279640921

From nbenalla at openjdk.org  Wed Sep  4 10:36:51 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 10:36:51 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
Message-ID: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>

The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.

The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.

This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.


`[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
`[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
`[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
`[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)



`test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.

Tests broken by these methods are :


jdk/classfile/VerifierSelfTest.java
jdk/classfile/TestRecordComponent.java
jdk/classfile/TestNullHostile.java	
jdk/classfile/OpcodesValidationTest.java
jdk/classfile/ClassPrinterTest.java
java/lang/invoke/MethodHandlesGeneralTest.java	
java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
java/lang/invoke/MethodHandleProxies/BasicTest.java


Full list of methods


//the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
"java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",

// making this method null-hostile causes a BootstapMethodError during the the build
//        java.lang.BootstrapMethodError: bootstrap method initialization exception
//        Caused by: java.lang.invoke.LambdaConversionException: Exception instantiating lambda object
"java.lang.classfile.CodeBuilder/loadConstant(java.lang.constant.ConstantDesc)/0/0",
"java.lang.classfile.CodeBuilder$BlockCodeBuilder/loadConstant(java.lang.constant.ConstantDesc)/0/0",



//removing these from exclude list breaks CorpusTest and AdvancedTransformationsTest
"java.lang.classfile.ClassHierarchyResolver$ClassHierarchyInfo/ofClass(java.lang.constant.ClassDesc)/0/0",
"java.lang.classfile.attribute.ModuleAttribute$ModuleAttributeBuilder/requires(java.lang.constant.ModuleDesc,int,java.lang.String)/2/0",
"java.lang.classfile.attribute.ModuleAttribute/of(java.lang.classfile.constantpool.ModuleEntry,int,java.lang.classfile.constantpool.Utf8Entry,java.util.Collection,java.util.Collection,java.util.Collection,java.util.Collection,java.util.Collection)/2/0",
"java.lang.classfile.attribute.ModuleRequireInfo/of(java.lang.classfile.constantpool.ModuleEntry,int,java.lang.classfile.constantpool.Utf8Entry)/2/0",
"java.lang.classfile.AttributeMapper/readAttribute(java.lang.classfile.AttributedElement,java.lang.classfile.ClassReader,int)/0/0",

// this one from exclude list breaksa few more tests
"java.lang.classfile.AttributeMapper/readAttribute(java.lang.classfile.AttributedElement,java.lang.classfile.ClassReader,int)/1/0",

// this one breaks jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java
"java.lang.classfile.ClassHierarchyResolver/ofClassLoading(java.lang.ClassLoader)/0/0",

//I need to revisit these
"java.lang.classfile.ClassFileTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.ClassFileTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.ClassTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",

//can we add stronger checks here?
"java.lang.classfile.components.CodeStackTracker/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.components.CodeStackTracker/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.CodeTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.CodeTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.FieldTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.FieldTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.components.CodeLocalsShifter/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.components.CodeLocalsShifter/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.components.CodeRelabeler/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",
"java.lang.classfile.components.CodeRelabeler/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.MethodTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/0/0",
"java.lang.classfile.MethodTransform/accept(java.lang.classfile.ClassFileBuilder,java.lang.classfile.ClassFileElement)/1/0",

// implementation calls these method with null
"java.lang.classfile.Signature$ClassTypeSig/of(java.lang.classfile.Signature$ClassTypeSig,java.lang.constant.ClassDesc,java.lang.classfile.Signature$TypeArg[])/0/0",
"java.lang.classfile.Signature$ClassTypeSig/of(java.lang.classfile.Signature$ClassTypeSig,java.lang.String,java.lang.classfile.Signature$TypeArg[])/0/0",
"java.lang.classfile.Signature$TypeParam/of(java.lang.String,java.lang.classfile.Signature$RefTypeSig,java.lang.classfile.Signature$RefTypeSig[])/1/0",
"java.lang.classfile.BufWriter/writeIndexOrZero(java.lang.classfile.constantpool.PoolEntry)/0/0"

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

Commit messages:
 - Tiny changes, some variable renames
 - Changes after JDK-8339214
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - - Passes all tests, a lot of comments for future work and questions
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - drop unused test file
 - Add more null checks, added some todos for methods that need to be revisited.
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - add requiresnonnull where necessary
 - Merge remote-tracking branch 'origin/master' into classfile-nulls
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ad40a122...2902e21d

Changes: https://git.openjdk.org/jdk/pull/20556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317356
  Stats: 1458 lines in 85 files changed: 1388 ins; 20 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/20556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20556/head:pull/20556

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

From liach at openjdk.org  Wed Sep  4 10:36:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 10:36:51 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <fs8pnMF8Utlb_BXUiZ2ps2gfgUtfuzGW_bkcnZ0ehxU=.91be6c38-2470-4235-b105-51a63bea70e0@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

? Reveals a lot of inconsistencies in the API. Many are remarks for future RFEs.

I doubt this is more of a conformance instead of a functional test - and this test cannot effectively test the cases where some object states will have code paths that do not throw NPE.

Indeed, `ConstantInstruction.ofArgument` needs a null check now. The other APIs should be fine as-is.

src/java.base/share/classes/java/lang/classfile/Annotation.java line 100:

> 98:                          List<AnnotationElement> elements) {
> 99:         requireNonNull(annotationClass);
> 100:         requireNonNull(elements);

How did you test these? Shouldn't null elements result in an NPE in `List.copyOf`?

src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java line 1:

> 1: /*

Methods here technically shouldn't be called by users; they only exist for the API to call, and for chained transforms, API don't call these and they throw UOE. We should look for another way to handle this.

src/java.base/share/classes/java/lang/classfile/Signature.java line 162:

> 160:          * @param typeArgs signatures of the type arguments
> 161:          */
> 162:         public static ClassTypeSig of(ClassTypeSig outerType, ClassDesc className, TypeArg... typeArgs) {

Another instance of nullable argument... I thought @asotona expressed that we wish to convert nullable args to `Optional`. Need to make such parameters consistent across the ClassFile API.

test/jdk/jdk/classfile/testdata/TestClass.java line 1:

> 1: package testdata;

File seems redundant? Or did you forget to upload the test driver?

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

PR Review: https://git.openjdk.org/jdk/pull/20556#pullrequestreview-2276280243
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2288755193
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2326604717
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741341522
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741340877
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741342557
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741343202

From duke at openjdk.org  Wed Sep  4 10:36:53 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 4 Sep 2024 10:36:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <maK1p1b93HA794FpXTYHy1erVLvVJfZUMNnB-6SruEM=.b4319da2-449f-4faa-a961-75a11b90a258@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

> And this test cannot effectively test the cases where some object states will have code paths that do not throw NPE.

**Ref:** [JDK?8336430](https://bugs.openjdk.org/browse/JDK-8336430)

Since?this now?makes the?NPE?behaviour of?[`Utf8Entry?::equalsString?(String)`]?consistent, this?PR can?be?marked as?fixing [JDK?8336430].

[`Utf8Entry?::equalsString?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/Utf8Entry.html#equalsString(java.lang.String)
[JDK?8336430]: https://bugs.openjdk.org/browse/JDK-8336430

src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 88:

> 86:             //todo: uncomment later
> 87:             // this causes CorpusTest to fail
> 88:             // requireNonNull(superClass);

This?is?valid, as?the?super class?descriptor of?`java.lang.Object` is?`null` (it?s?the?only one?allowed and?required to?extend?`null`).
Suggestion:

src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 226:

> 224:     static ClassHierarchyResolver ofClassLoading(ClassLoader loader) {
> 225:         //null check here breaks WithSecurityManagerTest
> 226: //        requireNonNull(loader);

The `null` `ClassLoader` is?valid and?refers to?either the?system or?bootstrap class?loader (depending on the API).

In?the?case of?[`Class?::forName(?)`], it?s?the?bootstrap class?loader (which?is?represented by?`null` (`Object.class.getClassLoader()` returns?`null`!))
Suggestion:



[`Class?::forName(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 622:

> 620:     default CodeBuilder loadConstant(ConstantDesc value) {
> 621: //        adding null check here causes error
> 622: //        requireNonNull(value);

This?method is?specified as?allowing?`null`?below.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 144:

> 142:         requireNonNull(moduleName);
> 143:         //todo should moduleVersion be Nullable?
> 144: //        requireNonNull(moduleVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 240:

> 238:             requireNonNull(module);
> 239:             requireNonNull(requiresFlags);
> 240:             requireNonNull(version);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 93:

> 91:         requireNonNull(requires);
> 92:         //todo: uncomment later after CorpusTest is fixed
> 93: //        requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 104:

> 102:      */
> 103:     static ModuleRequireInfo of(ModuleEntry requires, Collection<AccessFlag> requiresFlags, Utf8Entry requiresVersion) {
> 104:         requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 106:

> 104:         requireNonNull(requiresVersion);
> 105:         requireNonNull(requiresFlags);
> 106:         requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 118:

> 116:     static ModuleRequireInfo of(ModuleDesc requires, int requiresFlags, String requiresVersion) {
> 117:         requireNonNull(requires);
> 118:         requireNonNull(requiresVersion);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 385:

> 383:         @Override
> 384:         public boolean equalsString(String s) {
> 385:             Objects.requireNonNull(s);

I?d?prefer if?this?method returned?`false` on?`null`, just?like how?[`Object?::equals?(Object)`] and?[`String?::equalsIgnoreCase?(String)`] return?`false` on?`null`.

[`Object?::equals?(Object)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#equals(java.lang.Object)
[`String?::equalsIgnoreCase?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#equalsIgnoreCase(java.lang.String)

src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 78:

> 76:     public ClassFileImpl withOptions(Option... options) {
> 77:         requireNonNull(options);
> 78:         for (var o : options){

Suggestion:

        for (var o : options) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 101:

> 99:         requireNonNull(clb);
> 100:         requireNonNull(cle);
> 101:         switch (cle) {

Suggestion:

        switch (cle) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 280:

> 278:     @Override
> 279:     public ClassDesc map(ClassDesc desc) {
> 280:         requireNonNull(desc);

Allowed?below:
Suggestion:

src/java.base/share/classes/jdk/internal/classfile/impl/CodeLocalsShifterImpl.java line 54:

> 52:         Objects.requireNonNull(cob);
> 53:         Objects.requireNonNull(coe);
> 54:         switch (coe) {

Suggestion:

        switch (coe) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/CodeRelabelerImpl.java line 55:

> 53:         requireNonNull(cob);
> 54:         requireNonNull(coe);
> 55:         switch (coe) {

Suggestion:

        switch (coe) { // implicit null-check

src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java line 83:

> 81:     @Override
> 82:     public ModuleAttributeBuilder moduleVersion(String version) {
> 83:         requireNonNull(version);

Module?version is?`null`able by?Module?spec.
Suggestion:

src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java line 92:

> 90:         requireNonNull(module);
> 91:         // todo this crashes corpus test??
> 92: //        requireNonNull(version);

Module?version is?`null`able by?Module?spec.
Suggestion:

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

PR Review: https://git.openjdk.org/jdk/pull/20556#pullrequestreview-2278167656
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2288819265
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2325306146
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742497978
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742496132
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742500730
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742505667
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742512822
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742505172
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742523836
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742523525
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742523581
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1739220025
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742526544
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742527119
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742528052
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742528767
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742529154
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742510632
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742510377

From nbenalla at openjdk.org  Wed Sep  4 10:36:53 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 10:36:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <h4Ime_qdU_ug4Zqc9y2RgFxhJHtkXbIIcHIfPC10xdo=.eeb07b4c-7072-48e0-a823-5b3eacae6c3a@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

**Edit: the entire list has now been checked**

I now have some tests that pick up on the bug in `Utf8Entry::equalsString`.
I have added `Objects::requireNonNull` in a few places, will do an other scan when I'm done to remove a few that may be redundant, as the null check is sometimes implicit.
Classes/Interfaces that I haven't tested yet are the following 

AttributeMapper
AttributeMapper.AttributeStability
BufWriter
ClassBuilder
ClassFileElement
ClassFileTransform
ClassHierarchyResolver.ClassHierarchyInfo
ClassModel
ClassReader
ClassSignature
ClassTransform
CodeBuilder
CodeBuilder.CatchBuilder
CodeBuilder.BlockCodeBuilder
CodeElement
CodeTransform
CompoundElement
FieldBuilder
FieldTransform
MethodBuilder
MethodElement
MethodSignature
MethodTransform
Opcode
Opcode.Kind
Signature.ArrayTypeSig
Signature.BaseTypeSig
Signature.TypeArg
Signature.TypeArg.Bounded
Signature.TypeArg.Bounded.WildcardIndicator
Signature.TypeArg.Unbounded
Signature.ClassTypeSig
Signature.ThrowableSig
Signature.TypeParam
Signature.TypeVarSig
Signature.RefTypeSig
TypeAnnotation.TargetInfo
TypeAnnotation.TypePathComponent
TypeAnnotation.TypePathComponent.Kind
TypeAnnotation.TypeArgumentTarget
TypeAnnotation.OffsetTarget
TypeAnnotation.CatchTarget
TypeAnnotation.LocalVarTargetInfo
TypeAnnotation.LocalVarTarget
TypeAnnotation.ThrowsTarget
TypeAnnotation.FormalParameterTarget
TypeAnnotation.EmptyTarget
TypeAnnotation.TypeParameterBoundTarget
TypeAnnotation.SupertypeTarget
TypeAnnotation.TypeParameterTarget
TypeAnnotation.TargetType
AnnotationDefaultAttribute
BootstrapMethodsAttribute
ModuleAttribute.ModuleAttributeBuilder
ModuleExportInfo
ModuleHashInfo
ModuleHashesAttribute
ModuleMainClassAttribute
ModuleOpenInfo
ModulePackagesAttribute
ModuleProvideInfo
ModuleRequireInfo
ModuleResolutionAttribute
ModuleTargetAttribute
ClassPrinter.MapNode
ClassPrinter.ListNode
ClassPrinter.LeafNode
ClassPrinter.Node
ClassRemapper
CodeLocalsShifter
CodeRelabeler

Thanks for keeping track of this PR, I will do one more push tomorrow and open it.

I shaved 500 lines from the test I was using, I can probably make it more concise with more time.

Adding null checks breaks some tests (sometimes even the build), some are method handles related but the rest are limited to CF. 

I have filed [JDK-8339344](https://bugs.openjdk.org/browse/JDK-8339344) but more Bugs/RFEs will need to be filed.

I will modify the PR's body with some questions on which methods can be added to `TestNullHostile##EXCLUDE_LIST` and which need to be updated.

Also, I noticed a recent push (#20779) removing `CodeBuilder.loadConstant(Opcode, ConstantDesc)` which had been a major source of pain today. Will merge in a bit.

An other want I want to discuss is CodeBuilder.loadConstant(ConstantDesc value).

It [handles nulls ](https://github.com/openjdk/jdk/blob/ad40a122d632d65052b71125c0dfd58c54e3a521/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L614), and adding a null check causes a `BootstrapMethodError` during the build

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

PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2321858976
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2325417395
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2326579191
PR Comment: https://git.openjdk.org/jdk/pull/20556#issuecomment-2326627971

From liach at openjdk.org  Wed Sep  4 10:36:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 10:36:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <maK1p1b93HA794FpXTYHy1erVLvVJfZUMNnB-6SruEM=.b4319da2-449f-4faa-a961-75a11b90a258@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <maK1p1b93HA794FpXTYHy1erVLvVJfZUMNnB-6SruEM=.b4319da2-449f-4faa-a961-75a11b90a258@github.com>
Message-ID: <gWN6eFDdHqCKZ9kh66EkSVPMJMxNluIcYWpoFZgP6E0=.64408161-1be7-4e76-aacd-790180ab1ea0@github.com>

On Tue, 3 Sep 2024 18:27:48 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
>> 
>> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
>> 
>> 
>> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
>> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
>> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
>> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
>> 
>> 
>> 
>> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
>> 
>> Tests broken by these methods are :
>> 
>> 
>> jdk/classfile/VerifierSelfTest.java
>> jdk/classfile/TestRecordComponent.java
>> jdk/classfile/TestNullHostile.java	
>> jdk/classfile/OpcodesValidationTest.java
>> jdk/classfile/ClassPrinterTest.java
>> java/lang/invoke/MethodHandlesGeneralTest.java	
>> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
>> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
>> java/lang/invoke/MethodHandleProxies/BasicTest.java
>> 
>> 
>> Full list of methods
>> 
>> 
>> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
>> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
>> 
>> // making this method null-hostile causes a BootstapMethodError during the the...
>
> src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 226:
> 
>> 224:     static ClassHierarchyResolver ofClassLoading(ClassLoader loader) {
>> 225:         //null check here breaks WithSecurityManagerTest
>> 226: //        requireNonNull(loader);
> 
> The `null` `ClassLoader` is?valid and?refers to?either the?system or?bootstrap class?loader (depending on the API).
> 
> In?the?case of?[`Class?::forName(?)`], it?s?the?bootstrap class?loader (which?is?represented by?`null` (`Object.class.getClassLoader()` returns?`null`!))
> Suggestion:
> 
> 
> 
> [`Class?::forName(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

We intend to avoid using `null` to represent bootstrap class loader here, like in `MethodType`: https://github.com/openjdk/jdk/blob/bbb516163d400a9c7e923e423fe2a60091b59322/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1197

> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 622:
> 
>> 620:     default CodeBuilder loadConstant(ConstantDesc value) {
>> 621: //        adding null check here causes error
>> 622: //        requireNonNull(value);
> 
> This?method is?specified as?allowing?`null`?below.
> Suggestion:

We are thinking about whether to allow nullable or enforce `Optional` across the ClassFile API. So this may be changed to accept an `Optional` in the future.

> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 385:
> 
>> 383:         @Override
>> 384:         public boolean equalsString(String s) {
>> 385:             Objects.requireNonNull(s);
> 
> I?d?prefer if?this?method returned?`false` on?`null`, just?like how?[`Object?::equals?(Object)`] and?[`String?::equalsIgnoreCase?(String)`] return?`false` on?`null`.
> 
> [`Object?::equals?(Object)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#equals(java.lang.Object)
> [`String?::equalsIgnoreCase?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#equalsIgnoreCase(java.lang.String)

We should have noted clearly that the intended use case is for a read utf8 to compare to an existing string, like a method name, so we can minimally inflate a utf8 to perform a comparison. This means that there is little purpose of using `null` here, just like for any other Class-File API endpoints.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742619721
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1742622251
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1739266003

From nbenalla at openjdk.org  Wed Sep  4 10:36:54 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 10:36:54 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <fs8pnMF8Utlb_BXUiZ2ps2gfgUtfuzGW_bkcnZ0ehxU=.91be6c38-2470-4235-b105-51a63bea70e0@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <fs8pnMF8Utlb_BXUiZ2ps2gfgUtfuzGW_bkcnZ0ehxU=.91be6c38-2470-4235-b105-51a63bea70e0@github.com>
Message-ID: <GFVLh9Yx29xWv_6mq7I3cJjScuok6LPK8gSuQBmu70Y=.1f211f27-51b5-4594-ac1d-1fb43c350365@github.com>

On Tue, 3 Sep 2024 01:58:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
>> 
>> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
>> 
>> 
>> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
>> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
>> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
>> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
>> 
>> 
>> 
>> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
>> 
>> Tests broken by these methods are :
>> 
>> 
>> jdk/classfile/VerifierSelfTest.java
>> jdk/classfile/TestRecordComponent.java
>> jdk/classfile/TestNullHostile.java	
>> jdk/classfile/OpcodesValidationTest.java
>> jdk/classfile/ClassPrinterTest.java
>> java/lang/invoke/MethodHandlesGeneralTest.java	
>> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
>> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
>> java/lang/invoke/MethodHandleProxies/BasicTest.java
>> 
>> 
>> Full list of methods
>> 
>> 
>> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
>> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
>> 
>> // making this method null-hostile causes a BootstapMethodError during the the...
>
> test/jdk/jdk/classfile/testdata/TestClass.java line 1:
> 
>> 1: package testdata;
> 
> File seems redundant? Or did you forget to upload the test driver?

I thought I removed `testClass.java` as I no longer use it.

I will include a regression test tomorrow with the next patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1741345363

From redestad at openjdk.org  Wed Sep  4 11:09:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Sep 2024 11:09:24 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
Message-ID: <uDPrgErrMm6NSOXAjweXj3bMJuoyOJUuSeAU6Fj6ymM=.de390be1-2cde-4c3d-b788-0cb8994f8820@github.com>

On Tue, 3 Sep 2024 16:27:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize for utf16

I think this looks good now. A few minor nits you can deal with as you like.

src/java.base/share/classes/java/lang/StringCoding.java line 43:

> 41:     public static int countNonZeroAscii(String s) {
> 42:         byte[] value = s.value();
> 43:         int strlen = value.length;

Unused local variable, and `strlen` is a poor name for `value.length` (as it's only equal to `String::length` for latin1 strings)

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 322:

> 320: 
> 321:     /**
> 322:      * Count the number of leading non-zero ascii chars in the range.

Suggestion:

     * Count the number of leading non-zero ascii chars in the String.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 165:

> 163:         int countNonZeroAscii = JLA.countNonZeroAscii(str);
> 164:         int utflen = strlen;
> 165:         if (countNonZeroAscii != strlen) {

Perhaps skip the count if `strlen` is already too large (we'll throw in the next block)
Suggestion:

        if (strlen <= 65535 && countNonZeroAscii != strlen) {

test/jdk/java/lang/String/CountNonZeroAscii.java line 49:

> 47: 
> 48:         for (int i = 0; i < bytes.length; i++) {
> 49:             Arrays.fill(bytes, (byte) 'A');

Not sure it matters but this can be avoided if you add a `bytes[i] = (byte) 'A';` after creating `s` in the loop below.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2279730112
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1743523945
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1743530502
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1743542942
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1743550976

From daniel.fuchs at oracle.com  Wed Sep  4 11:11:32 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 4 Sep 2024 12:11:32 +0100
Subject: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under
 high contention and suggestion for fair mode in ArrayBlockingQueue and
 LinkedBlockingQueue
In-Reply-To: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
Message-ID: <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>

Hi Kim,

When several threads compete to put items in a queue,
regardless of queue locking strategies, nothing guarantees
the order in which items will end up in the queue if
the action of obtaining the next element and putting
it in the queue is not atomic. This is because a thread
can be preempted by the scheduler at any time between
two operations.

Consider the following scenario:

you have a sequence of ordered items a, b, c, one queue q,
and two threads T1, T2 and T3:

T1 starts, obtains element a, and gets preempted (the thread
    is paused by the scheduler).
T2 starts, obtains element b and puts it in the queue.
T3 starts, obtains element c and gets preempted.
T1 gets scheduled again and puts a in the queue.
T3 gets scheduled again and puts c in the queue.

result: the queue contains b a c; regardless of whether
the queue uses fair or unfair locking, the order of items
in the queue will be unpredictable. And in this scenario,
there isn't even any contention on the queue.

To ensure that items will end up in the queue in the proper
order would require an additional lock at the application
level.

That is - you would need to use a lock so that taking
an element from the sequenceGenerator and putting it in the
queue becomes atomic (with respect to the queue).

so in your example you would need something like:

static ReentrantLock lock = new ReentrantLock();
...

       Thread thread = new Thread(() -> {
             lock.lock();
             try {
                 var token = sequenceGenerator.getAndIncrement();
                 // even if this thread gets preempted here, no
                 // other thread will be able to obtain the next
                 // token before our token has been put in the queue
                 try {
                     queue.put(token);
                 } catch (InterruptedException e) {
                     // restore the sequence
                     var restored = sequenceGenerator.decrementAndGet();
                     assert token == restored;
                 }
             } finally {
                 lock.unlock();
             }

         });
         thread.start();

best regards,

-- daniel

On 04/09/2024 08:09, ??? wrote:
> // This configuration ensures items enter the queue's waiting list in a 
> predictable sequence (10, 11, 12, ...) // allowing us to verify if they 
> are later consumed in the same order for (int i = 0; i < PRODUCER_COUNT; 
> i++) { Thread thread = new Thread(() -> { try { 
> queue.put(sequenceGenerator.getAndIncrement()); } catch 
> (InterruptedException e) { // ignore } });


From jvernee at openjdk.org  Wed Sep  4 11:41:24 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 11:41:24 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <zygRGCJzlGdAVCN6rTqBI-YsIpHL87WRLqKAgzr6yLM=.9c46f227-6bc5-4411-acb4-ff471dfe5291@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <zygRGCJzlGdAVCN6rTqBI-YsIpHL87WRLqKAgzr6yLM=.9c46f227-6bc5-4411-acb4-ff471dfe5291@github.com>
Message-ID: <5rZOqWZ627bnEJ66wW7Qqye-ZYeAjsK1083MG5GELLk=.c5c144f0-a1a0-483c-ac21-3a948502c3be@github.com>

On Wed, 4 Sep 2024 01:29:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> src/hotspot/share/prims/upcallLinker.cpp line 142:
> 
>> 140:   Handle exception_h(Thread::current(), exception);
>> 141:   java_lang_Throwable::print_stack_trace(exception_h, tty);
>> 142:   ShouldNotReachHere();
> 
> How does `print_stack_trace` not return here?

It does return. `ShouldNotReachHere` is used to crash the VM.

> test/jdk/java/foreign/TestUpcallStress.java line 27:
> 
>> 25:  * @test
>> 26:  * @requires jdk.foreign.linker != "FALLBACK"
>> 27:  * @requires os.arch == "aarch64" & os.name == "Linux"
> 
> Only for Linux-aarch64 ??

Yes. The test is very unstable, and the issue is only reproducible on Linux/aarch64 any way. See https://github.com/openjdk/jdk/pull/20479#issuecomment-2278175462

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743609798
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743607061

From mbaesken at openjdk.org  Wed Sep  4 11:42:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Sep 2024 11:42:20 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <UJ90n2n2eCJXBLr1KOC1oUs17lFaKJmO4DbbjmlJDH8=.476fcc46-111a-4333-8914-e627b2203910@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>
 <UJ90n2n2eCJXBLr1KOC1oUs17lFaKJmO4DbbjmlJDH8=.476fcc46-111a-4333-8914-e627b2203910@github.com>
Message-ID: <Up6nQin3_Epxqe8MYRVtvOowIcc7u89vaHB6VMImbwk=.71804979-9aa0-49b8-baec-c6fa510d9e43@github.com>

On Wed, 4 Sep 2024 09:29:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In your investigations, is it the first or second call to sysctl(3) that is failing?

Unfortunately I don't know (but with this change and added JDK message text I would know next time).

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2328718717

From swen at openjdk.org  Wed Sep  4 11:44:54 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 11:44:54 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v18]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <zOxSPTKJU5eFvKM1tqfrFBp7akrHA3d7btHHkEP5I_4=.a1c978a2-bb74-481a-8029-b9809b613b3d@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  Update src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/059bece2..a6e05cde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=16-17

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

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

From sgehwolf at openjdk.org  Wed Sep  4 11:48:26 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Sep 2024 11:48:26 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
Message-ID: <P9dPj52o09OUL2gkttLZHH-Z8dovmfNVSkhX_MU-cp8=.28897a1c-0768-43a8-9a68-d562eb22b907@github.com>

On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim <duke at openjdk.org> wrote:

>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions

Not an expert in this area, so just a drive-by review.

test/hotspot/jtreg/runtime/BootClassAppendProp/BootClassPathZipFileCreator.java line 1:

> 1: /*

Shouldn't this be in `test/jdk/java/util/zip`?

test/hotspot/jtreg/runtime/BootClassAppendProp/BootClassPathZipFileCreator.java line 76:

> 74:             env.put("forceZIP64End", "true");
> 75:         }
> 76:         Path zip = Paths.get(System.getProperty("user.dir"), type + ".zip");

Should we use `test.classes` (i.e. `System.getProperty("test.classes", System.getProperty("user.dir")`) dir for those transient files?

test/hotspot/jtreg/runtime/BootClassAppendProp/BootClassPathZipFileTest.java line 49:

> 47:         // the ZIP file not existing is the same as the ZIP file not being
> 48:         // readable, that is, ClassNotFoundException on CLASS_NAME.
> 49:         Path zipPath = Paths.get(System.getProperty("user.dir"), args[0]);

`test.classes` here as well.

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

PR Review: https://git.openjdk.org/jdk/pull/19678#pullrequestreview-2279860073
PR Review Comment: https://git.openjdk.org/jdk/pull/19678#discussion_r1743599742
PR Review Comment: https://git.openjdk.org/jdk/pull/19678#discussion_r1743616270
PR Review Comment: https://git.openjdk.org/jdk/pull/19678#discussion_r1743616812

From miiiinju00 at gmail.com  Wed Sep  4 11:50:47 2024
From: miiiinju00 at gmail.com (=?UTF-8?B?6rmA66+87KO8?=)
Date: Wed, 4 Sep 2024 20:50:47 +0900
Subject: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under
 high contention and suggestion for fair mode in ArrayBlockingQueue and
 LinkedBlockingQueue
In-Reply-To: <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
Message-ID: <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>

Hi Daniel,

Thank you so much for your detailed insights in the previous email. I
completely agree with your point that ensuring atomicity between the token
retrieval (sequenceGenerator.getAndIncrement()) and placing it in the queue
(queue.put()) is crucial to avoid issues such as thread interleaving, which
could lead to tokens being inserted in an unpredictable order.

That being said, my goal with the original test was to simulate a situation
where multiple threads are competing to put items into a queue that?s
already full. In this case, I wanted the threads to block naturally when
the queue reaches capacity and then resume in the same order when space
becomes available. Essentially, I was trying to observe how threads would
be blocked in the order of their token retrieval and resume their
operations when the queue allows.

I now see that using a ReentrantLock to ensure atomicity across both the
token retrieval and the queue insertion can indeed prevent such
interleaving. However, a challenge arises when the queue?s capacity is
reached. Since LinkedBlockingQueue.put() causes the thread to block when
the queue is full, the thread holding the lock will not be able to release
it until space becomes available in the queue. This can result in a
deadlock-like situation where other threads are unable to acquire the lock
to retrieve their own tokens.

In other words, while the use of a lock ensures atomicity, it can
inadvertently cause issues when the queue is full. Specifically, the thread
holding the lock gets blocked while waiting for space in the queue and
cannot release the lock, which in turn prevents other threads from
acquiring the lock to retrieve their own tokens. This leads to a situation
where multiple threads are stuck waiting for both the lock and space in the
queue, causing a deadlock-like scenario.

This was one of the key reasons why I initially implemented the token
retrieval and queue insertion steps with non-locking.

In the original approach, I intended for each thread to call put, confirm
that it has entered the waiting state, and then allow the next thread to
put the next sequence value and also enter the waiting state. This approach
was designed to simulate a situation where the queue is already full and
each thread has to wait in line for space to become available.

2024? 9? 4? (?) ?? 8:11, Daniel Fuchs <daniel.fuchs at oracle.com>?? ??:

> Hi Kim,
>
> When several threads compete to put items in a queue,
> regardless of queue locking strategies, nothing guarantees
> the order in which items will end up in the queue if
> the action of obtaining the next element and putting
> it in the queue is not atomic. This is because a thread
> can be preempted by the scheduler at any time between
> two operations.
>
> Consider the following scenario:
>
> you have a sequence of ordered items a, b, c, one queue q,
> and two threads T1, T2 and T3:
>
> T1 starts, obtains element a, and gets preempted (the thread
>     is paused by the scheduler).
> T2 starts, obtains element b and puts it in the queue.
> T3 starts, obtains element c and gets preempted.
> T1 gets scheduled again and puts a in the queue.
> T3 gets scheduled again and puts c in the queue.
>
> result: the queue contains b a c; regardless of whether
> the queue uses fair or unfair locking, the order of items
> in the queue will be unpredictable. And in this scenario,
> there isn't even any contention on the queue.
>
> To ensure that items will end up in the queue in the proper
> order would require an additional lock at the application
> level.
>
> That is - you would need to use a lock so that taking
> an element from the sequenceGenerator and putting it in the
> queue becomes atomic (with respect to the queue).
>
> so in your example you would need something like:
>
> static ReentrantLock lock = new ReentrantLock();
> ...
>
>        Thread thread = new Thread(() -> {
>              lock.lock();
>              try {
>                  var token = sequenceGenerator.getAndIncrement();
>                  // even if this thread gets preempted here, no
>                  // other thread will be able to obtain the next
>                  // token before our token has been put in the queue
>                  try {
>                      queue.put(token);
>                  } catch (InterruptedException e) {
>                      // restore the sequence
>                      var restored = sequenceGenerator.decrementAndGet();
>                      assert token == restored;
>                  }
>              } finally {
>                  lock.unlock();
>              }
>
>          });
>          thread.start();
>
> best regards,
>
> -- daniel
>
> On 04/09/2024 08:09, ??? wrote:
> > // This configuration ensures items enter the queue's waiting list in a
> > predictable sequence (10, 11, 12, ...) // allowing us to verify if they
> > are later consumed in the same order for (int i = 0; i < PRODUCER_COUNT;
> > i++) { Thread thread = new Thread(() -> { try {
> > queue.put(sequenceGenerator.getAndIncrement()); } catch
> > (InterruptedException e) { // ignore } });
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/5c504f4f/attachment-0001.htm>

From swen at openjdk.org  Wed Sep  4 11:51:56 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 11:51:56 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v19]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <A6m9tPrMVfF_lIIFDMW7ZB7Te5tp9nSoIJ291I4rsSA=.9386bcd1-dd05-4dec-99ce-e071c23f8f73@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  Unused local variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/a6e05cde..7d1b2631

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=17-18

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

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

From swen at openjdk.org  Wed Sep  4 11:51:56 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 11:51:56 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <uDPrgErrMm6NSOXAjweXj3bMJuoyOJUuSeAU6Fj6ymM=.de390be1-2cde-4c3d-b788-0cb8994f8820@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
 <uDPrgErrMm6NSOXAjweXj3bMJuoyOJUuSeAU6Fj6ymM=.de390be1-2cde-4c3d-b788-0cb8994f8820@github.com>
Message-ID: <lCBt_zkM7e3Qb_Egv7Cfp78qz3diYoq3wZ0yNGPTaQE=.2629992d-44bd-42bb-a798-45394626fc51@github.com>

On Wed, 4 Sep 2024 10:59:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   optimize for utf16
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 165:
> 
>> 163:         int countNonZeroAscii = JLA.countNonZeroAscii(str);
>> 164:         int utflen = strlen;
>> 165:         if (countNonZeroAscii != strlen) {
> 
> Perhaps skip the count if `strlen` is already too large (we'll throw in the next block)
> Suggestion:
> 
>         if (strlen <= 65535 && countNonZeroAscii != strlen) {

Let?s not add this, because normal logic should not pay the cost for abnormal logic

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1743626412

From redestad at openjdk.org  Wed Sep  4 11:57:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Sep 2024 11:57:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <lCBt_zkM7e3Qb_Egv7Cfp78qz3diYoq3wZ0yNGPTaQE=.2629992d-44bd-42bb-a798-45394626fc51@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
 <uDPrgErrMm6NSOXAjweXj3bMJuoyOJUuSeAU6Fj6ymM=.de390be1-2cde-4c3d-b788-0cb8994f8820@github.com>
 <lCBt_zkM7e3Qb_Egv7Cfp78qz3diYoq3wZ0yNGPTaQE=.2629992d-44bd-42bb-a798-45394626fc51@github.com>
Message-ID: <MBSO7fpy1YdBjhR7dyi3uM0ZtvA9wSUFINMM2gE4530=.09337a2e-dca1-4ff2-a73b-59caf5176a20@github.com>

On Wed, 4 Sep 2024 11:48:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 165:
>> 
>>> 163:         int countNonZeroAscii = JLA.countNonZeroAscii(str);
>>> 164:         int utflen = strlen;
>>> 165:         if (countNonZeroAscii != strlen) {
>> 
>> Perhaps skip the count if `strlen` is already too large (we'll throw in the next block)
>> Suggestion:
>> 
>>         if (strlen <= 65535 && countNonZeroAscii != strlen) {
>
> Let?s not add this, because normal logic should not pay the cost for abnormal logic

Agreed in principle, but not sure the cost of this quick fail-fast sanity test would be noticeable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1743636412

From jvernee at openjdk.org  Wed Sep  4 11:58:20 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 11:58:20 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <5rZOqWZ627bnEJ66wW7Qqye-ZYeAjsK1083MG5GELLk=.c5c144f0-a1a0-483c-ac21-3a948502c3be@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <zygRGCJzlGdAVCN6rTqBI-YsIpHL87WRLqKAgzr6yLM=.9c46f227-6bc5-4411-acb4-ff471dfe5291@github.com>
 <5rZOqWZ627bnEJ66wW7Qqye-ZYeAjsK1083MG5GELLk=.c5c144f0-a1a0-483c-ac21-3a948502c3be@github.com>
Message-ID: <NsQx15dDzClD-cOMpku-iG_fydsHnMtILX0kFtRka6w=.4c996cf7-24a7-4bee-b466-c8bd7854dfd3@github.com>

On Wed, 4 Sep 2024 11:39:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/prims/upcallLinker.cpp line 142:
>> 
>>> 140:   Handle exception_h(Thread::current(), exception);
>>> 141:   java_lang_Throwable::print_stack_trace(exception_h, tty);
>>> 142:   ShouldNotReachHere();
>> 
>> How does `print_stack_trace` not return here?
>
> It does return. `ShouldNotReachHere` is used to crash the VM.

`fatal()` might be better here. I could change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743638097

From jvernee at openjdk.org  Wed Sep  4 12:01:24 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 12:01:24 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <yL-Cf6a0eIZko_BfkudPfyGpaDP6hGCDl4sdbRxQ3jw=.37886e1b-e6d3-4abd-bde3-d988804f8f36@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <yL-Cf6a0eIZko_BfkudPfyGpaDP6hGCDl4sdbRxQ3jw=.37886e1b-e6d3-4abd-bde3-d988804f8f36@github.com>
Message-ID: <O5IUCiFqW0VrLg40v3c4UI1lis3NBVheodpFcrkRxdI=.13aedc31-c5a0-407c-a0b9-b1377c9e9495@github.com>

On Wed, 4 Sep 2024 06:14:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 264:
> 
>> 262: 
>> 263:   __ block_comment("{ load target ");
>> 264:   __ movptr(j_rarg0, (intptr_t) receiver);
> 
> Hi @JornVernee , Could you please apply following small add-on change for linux-riscv64? As I witnessed build warning with GCC-13. Otherwise, builds fine and the newly-added test/jdk/java/foreign/TestUpcallStress.java is passing. (PS: jdk_foreign tests are passing too)
> 
> 
> diff --git a/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp b/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp
> index 5c45a679316..55160be99d0 100644
> --- a/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp
> +++ b/src/hotspot/cpu/riscv/upcallLinker_riscv.cpp
> @@ -261,7 +261,7 @@ address UpcallLinker::make_upcall_stub(jobject receiver, Symbol* signature,
>    __ block_comment("} argument shuffle");
> 
>    __ block_comment("{ load target ");
> -  __ movptr(j_rarg0, (intptr_t) receiver);
> +  __ movptr(j_rarg0, (address) receiver);
>    __ far_call(RuntimeAddress(StubRoutines::upcall_stub_load_target())); // loads Method* into xmethod
>    __ block_comment("} load target ");
> 
> diff --git a/test/jdk/java/foreign/TestUpcallStress.java b/test/jdk/java/foreign/TestUpcallStress.java
> index 3b9b1d4b207..40607746856 100644
> --- a/test/jdk/java/foreign/TestUpcallStress.java
> +++ b/test/jdk/java/foreign/TestUpcallStress.java
> @@ -24,7 +24,7 @@
>  /*
>   * @test
>   * @requires jdk.foreign.linker != "FALLBACK"
> - * @requires os.arch == "aarch64" & os.name == "Linux"
> + * @requires (os.arch == "aarch64" | os.arch=="riscv64") & os.name == "Linux"
>   * @requires os.maxMemory > 4G
>   * @modules java.base/jdk.internal.foreign
>   * @build NativeTestHelper CallGeneratorHelper TestUpcallBase

Were you able to reproduce the original issue on RISC-V?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743643186

From swen at openjdk.org  Wed Sep  4 12:01:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 12:01:37 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  from @cl4es 's suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/7d1b2631..c257cf36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=18-19

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

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

From alanb at openjdk.org  Wed Sep  4 12:07:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Sep 2024 12:07:19 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <Up6nQin3_Epxqe8MYRVtvOowIcc7u89vaHB6VMImbwk=.71804979-9aa0-49b8-baec-c6fa510d9e43@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>
 <UJ90n2n2eCJXBLr1KOC1oUs17lFaKJmO4DbbjmlJDH8=.476fcc46-111a-4333-8914-e627b2203910@github.com>
 <Up6nQin3_Epxqe8MYRVtvOowIcc7u89vaHB6VMImbwk=.71804979-9aa0-49b8-baec-c6fa510d9e43@github.com>
Message-ID: <HpSwVfxhjQCqVF2dHLv9JVvw0p5WZvmu23E-xZvp0NM=.ae3bd745-7c57-4cc7-b928-83a63269bf18@github.com>

On Wed, 4 Sep 2024 11:39:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Unfortunately I don't know (but with this change and added JDK message text I would know next time).

My guess is that it's the second call that is failing and the bug is that the number of processes increased between the first and second call to sysctl. I think we'll need to put a loop around this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2328791922

From mcimadamore at openjdk.org  Wed Sep  4 12:20:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Sep 2024 12:20:20 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <qfndU4QjJlLzR6Yrg7mBL-HNBEfmybwdmrCOEztzgAo=.5999d188-f548-4dc6-9ba0-a8f3adcba61f@github.com>

On Wed, 4 Sep 2024 09:09:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 103:

> 101:         } else {
> 102:             long i;
> 103:             if (SCOPED_MEMORY_ACCESS.getByte(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcToOffset) !=

Suggestion:

            if (SCOPED_MEMORY_ACCESS.getByte(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset) !=

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1743672410

From mbaesken at openjdk.org  Wed Sep  4 12:25:19 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Sep 2024 12:25:19 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <HpSwVfxhjQCqVF2dHLv9JVvw0p5WZvmu23E-xZvp0NM=.ae3bd745-7c57-4cc7-b928-83a63269bf18@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>
 <UJ90n2n2eCJXBLr1KOC1oUs17lFaKJmO4DbbjmlJDH8=.476fcc46-111a-4333-8914-e627b2203910@github.com>
 <Up6nQin3_Epxqe8MYRVtvOowIcc7u89vaHB6VMImbwk=.71804979-9aa0-49b8-baec-c6fa510d9e43@github.com>
 <HpSwVfxhjQCqVF2dHLv9JVvw0p5WZvmu23E-xZvp0NM=.ae3bd745-7c57-4cc7-b928-83a63269bf18@github.com>
Message-ID: <2lRpwwXrzplICv8dlaZ1D0CIx2BADRCw0b3R-qAOjlw=.471d4387-281f-4b94-a209-21c310963ce1@github.com>

On Wed, 4 Sep 2024 12:05:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Unfortunately I don't know (but with this change and added JDK message text I would know next time).
> 
> My guess is that it's the second call that is failing and the bug is that the number of processes increased between the first and second call to sysctl. I think we'll need to put a loop around this.

Hi , my guess is too that it is the second call.
In case we want to go for a loop, should we have a maximum number of retry operations like 10 or 100 ?
Another option might be to always make the buffer a little bigger (how much can be discussed)  and use the larger buffer to account  for some increase in the number of processes.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2328838545

From liach at openjdk.org  Wed Sep  4 12:30:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 12:30:24 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v5]
In-Reply-To: <jKzvN7v4pJl2INstuTMJgtQW1eOgiS_ZCFdSX6xxeCc=.1c5cb665-0dc1-465d-ba1e-db9de4f535df@github.com>
References: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
 <jKzvN7v4pJl2INstuTMJgtQW1eOgiS_ZCFdSX6xxeCc=.1c5cb665-0dc1-465d-ba1e-db9de4f535df@github.com>
Message-ID: <WMshGwLYMk-3pHTBNufKDngRwd7i3S5a7hWTgq_ydqQ=.def62ce7-3bc1-4d44-858e-91d136c02091@github.com>

On Wed, 4 Sep 2024 08:12:55 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
>> 
>> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.
>
> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright years and added a bug id

Thanks for the updates!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17818#pullrequestreview-2280014817

From liach at openjdk.org  Wed Sep  4 12:32:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 12:32:24 GMT
Subject: RFR: 8339131: Remove rarely-used accessor methods from Opcode [v2]
In-Reply-To: <dZH1WEvjeQuT_C9IJfAaQ-UAKUp5JFm7WV99SbvYBF0=.58991538-005c-419f-98dd-1e93c0debeb9@github.com>
References: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
 <dZH1WEvjeQuT_C9IJfAaQ-UAKUp5JFm7WV99SbvYBF0=.58991538-005c-419f-98dd-1e93c0debeb9@github.com>
Message-ID: <UTc4PpM0aOehYfcBLuY_a74E6RGbnm-y3hIOsgH2YCk=.494314eb-f905-4110-aa93-4cd1b2a804b8@github.com>

On Tue, 3 Sep 2024 23:22:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we agreed that current fields of `Opcode` violate data oriented design to a large extent. The attributes not generic to all opcode are removed.
>> 
>> Up for preliminary review; needs to be reworked for #20737.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Revert back to enum switch, fix compile error
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Fix ofArgument in loadConstant patch instead, improve specs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
>  - Clean up opcode fields

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/20757#issuecomment-2328853769

From liach at openjdk.org  Wed Sep  4 12:32:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 12:32:25 GMT
Subject: Integrated: 8339131: Remove rarely-used accessor methods from Opcode
In-Reply-To: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
References: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
Message-ID: <Cq_S40wF1lQfngP7TRPdQh7RI9jDZV9whcHmzGCMSWM=.de1ffa5a-ba75-4ec7-b83d-c6f3fb312ce6@github.com>

On Wed, 28 Aug 2024 22:41:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> In offline discussion, we agreed that current fields of `Opcode` violate data oriented design to a large extent. The attributes not generic to all opcode are removed.
> 
> Up for preliminary review; needs to be reworked for #20737.

This pull request has now been integrated.

Changeset: bd8569bc
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd8569bc6cc888cbf514e9329e2c24a059d89711
Stats:     469 lines in 8 files changed: 189 ins; 77 del; 203 mod

8339131: Remove rarely-used accessor methods from Opcode

Reviewed-by: asotona

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

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

From daniel.fuchs at oracle.com  Wed Sep  4 12:35:36 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 4 Sep 2024 13:35:36 +0100
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
Message-ID: <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>

Hi Kim,

On 04/09/2024 12:50, ??? wrote:
> In the original approach, I intended for each thread to call |put|, 
> confirm that it has entered the waiting state, and then allow the next 
> thread to put the next sequence value and also enter the waiting state. 
> This approach was designed to simulate a situation where the queue is 
> already full and each thread has to wait in line for space to become 
> available.

The problem with that is that you would still need to ensure that each
thread calls `put` in order, and for that, you would still need
external synchronization.

I am not an expert in java.util.concurrent, but it feels like the
fix you had in mind would not buy you much.

best regards,

-- daniel


From fyang at openjdk.org  Wed Sep  4 12:50:20 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 4 Sep 2024 12:50:20 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <O5IUCiFqW0VrLg40v3c4UI1lis3NBVheodpFcrkRxdI=.13aedc31-c5a0-407c-a0b9-b1377c9e9495@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <yL-Cf6a0eIZko_BfkudPfyGpaDP6hGCDl4sdbRxQ3jw=.37886e1b-e6d3-4abd-bde3-d988804f8f36@github.com>
 <O5IUCiFqW0VrLg40v3c4UI1lis3NBVheodpFcrkRxdI=.13aedc31-c5a0-407c-a0b9-b1377c9e9495@github.com>
Message-ID: <jMsfLqORAS12j6IyJgYiuQ6MmD-4-oFFZ_Inhr4E4VE=.90dde941-dfa3-4f1c-a4b1-f8e2d6ffc565@github.com>

On Wed, 4 Sep 2024 11:58:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Were you able to reproduce the original issue on RISC-V?

Yeah. I can reproduce similar crash on linux-riscv64 platform running this new test as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743722070

From jvernee at openjdk.org  Wed Sep  4 12:51:47 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 12:51:47 GMT
Subject: RFR: 8338123: Linker crash when building a downcall handle with many
 arguments in x64
Message-ID: <p0QPoSFPn70tvHFPFy3lVGc3Ch2HVznRxj_-Z1GAiJ0=.8b46bf40-3191-4e84-a07c-54155581d1f0@github.com>

- Adjust downcall stub sizes based on latest version. (per method described in https://github.com/openjdk/jdk/pull/12908)
- Beef up test for large stubs to also cover this particular case.

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

Commit messages:
 - use junit
 - make test more rebust
 - add test
 - adjust downcall stub sizes

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

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

From redestad at openjdk.org  Wed Sep  4 13:11:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Sep 2024 13:11:22 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>> 
>> Tested using `StackMapsTest`.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

LGTM

AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume getting rid of the `TreeMap` and `Integer` key allocations more than makes up for this, though. Do we have any JMH tests where `writeFrames` is a significant contributor we could check?

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20841#pullrequestreview-2280151482

From jvernee at openjdk.org  Wed Sep  4 13:11:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 13:11:57 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v2]
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <xiSuDHH5SDNHdqQACFolYhRlUxxkY1CjjuKr3tWFycw=.1528cf22-8815-4d38-8862-2fa240916ed0@github.com>

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

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

  Adjust ppc & RISC-V code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20479/files
  - new: https://git.openjdk.org/jdk/pull/20479/files/8dcb14ff..c478c08f

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

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

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

From miiiinju00 at gmail.com  Wed Sep  4 13:12:09 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Wed, 4 Sep 2024 22:12:09 +0900
Subject: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under
 high contention and suggestion for fair mode in ArrayBlockingQueue and
 LinkedBlockingQueue
In-Reply-To: <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
Message-ID: <CE67C148-3370-44D1-AE92-210BC1054551@gmail.com>

Dear Daniel,

Thank you for your insightful feedback on my approach. After carefully considering your points, I realize that I made a significant mistake in my initial implementation. I sincerely appreciate you bringing this to my attention.

You were absolutely correct in pointing out the potential issues with ensuring the order of put calls and the need for external synchronization. Upon review, I noticed that my original code was erroneously checking for NEW or RUNNABLE states, which, as you rightly suggested, doesn't guarantee that the thread has entered a waiting state. This was a clear oversight on my part.

Moreover, I now understand that using a while loop to check the thread state was fundamentally flawed. The awaitmethod is internally encapsulated within the BlockingQueue implementation, meaning there's no way to guarantee from outside the class that await has actually been called.

To address this error, I've modified the code as follows:

for (int i = 0; i < PRODUCER_COUNT; i++) {
            Thread thread = new Thread(() -> {
                try {
                    queue.put(sequenceGenerator.getAndIncrement());
                } catch (InterruptedException e) {
                    // ignore
                }

            });
            thread.start();
            // Wait for the producer thread to enter WAITING state
            // This ensures that the thread is waiting on the full queue
            while (thread.getState() != State.WAITING);
        }

Thread producingWhenConsumingThread = new Thread(() -> {
            for (int i = 0; i < PRODUCER_COUNT_WHEN_CONSUMING; i++) {
                Thread thread = new Thread(() -> {
                    try {
                        queue.put(sequenceGenerator.getAndIncrement());
                    } catch (InterruptedException e) {
                        // ignore
                    }

                });
                thread.start();

                // Wait for the producer thread to enter BLOCKED state
                // This ensures that the thread is waiting on the full queue

                // Terminated: queue has enough space to put the item, then the thread can terminate immediately
                while (thread.getState() != State.WAITING && thread.getState() != State.TERMINATED);

            }
        });
(Terminated: queue has enough space to put the item, then the thread can terminate immediately)

While this change ensures we're verifying that each thread has either entered a waiting state or completed its operation, I acknowledge that it still doesn't provide a perfect solution due to the encapsulation of the await method. This approach should more accurately simulate the scenario of multiple threads competing to put items into a full queue, without requiring external synchronization, but it has its limitations.

I believe this modification addresses some of the concerns you raised while still attempting to maintain the original intent of the test.

Your expertise and the time you've taken to review my work are greatly appreciated. Your feedback has been invaluable in helping me correct this mistake, improve the accuracy of this test, and most importantly, understand the limitations of trying to observe internal queue behaviors from outside.

I'm very interested in your thoughts on this updated approach and any suggestions you might have for better testing strategies given the encapsulation challenge. If you see any further areas for improvement or have additional insights, I'd be very eager to hear them.

Thank you once again for your help and for fostering this productive discussion. Your input has been crucial in refining my understanding and implementation, and in highlighting important aspects of concurrent programming that I had overlooked.



P.S. After further reflection, I wanted to add a note about the challenge of external synchronization in this context. My primary goal was to implement external synchronization as much as possible. However, due to the nature of the `await` operation, which is atomic and encapsulated within the `BlockingQueue` implementation, I found myself limited in options to verify that a thread had actually executed the `put` operation and entered a waiting state.

The while loop checking for the WAITING state seemed to be the only viable approach I could think of to indirectly confirm that a thread had called `put` and was now waiting. I acknowledge this is still an imperfect solution, as it doesn't guarantee the exact moment the thread entered the waiting state, nor does it provide true external synchronization.

I'm particularly interested in your thoughts on how we might better approach this challenge. Are there alternative methods to verify the atomic execution of `put` and the subsequent waiting state, while still maintaining as much external control as possible? Your expertise in this area would be greatly appreciated.

Best regards,

Kim Minju



> 2024. 9. 4. ?? 9:35, Daniel Fuchs <daniel.fuchs at oracle.com> ??:
> 
> Hi Kim,
> 
> On 04/09/2024 12:50, ??? wrote:
>> In the original approach, I intended for each thread to call |put|, confirm that it has entered the waiting state, and then allow the next thread to put the next sequence value and also enter the waiting state. This approach was designed to simulate a situation where the queue is already full and each thread has to wait in line for space to become available.
> 
> The problem with that is that you would still need to ensure that each
> thread calls `put` in order, and for that, you would still need
> external synchronization.
> 
> I am not an expert in java.util.concurrent, but it feels like the
> fix you had in mind would not buy you much.
> 
> best regards,
> 
> -- daniel
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/4f1d75f1/attachment.htm>

From jvernee at openjdk.org  Wed Sep  4 13:14:55 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 13:14:55 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <oHhJOAN_lqkj-AXZzUmk6nPcnrXSc6yaSqD3OLS2S_o=.0aab03c1-7621-4be3-85f1-aeafd6197ec9@github.com>

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

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

  add RISC-V as target platform

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20479/files
  - new: https://git.openjdk.org/jdk/pull/20479/files/c478c08f..1558ad9c

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

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

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

From jvernee at openjdk.org  Wed Sep  4 13:14:55 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Sep 2024 13:14:55 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <jMsfLqORAS12j6IyJgYiuQ6MmD-4-oFFZ_Inhr4E4VE=.90dde941-dfa3-4f1c-a4b1-f8e2d6ffc565@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <yL-Cf6a0eIZko_BfkudPfyGpaDP6hGCDl4sdbRxQ3jw=.37886e1b-e6d3-4abd-bde3-d988804f8f36@github.com>
 <O5IUCiFqW0VrLg40v3c4UI1lis3NBVheodpFcrkRxdI=.13aedc31-c5a0-407c-a0b9-b1377c9e9495@github.com>
 <jMsfLqORAS12j6IyJgYiuQ6MmD-4-oFFZ_Inhr4E4VE=.90dde941-dfa3-4f1c-a4b1-f8e2d6ffc565@github.com>
Message-ID: <7UkbLuak7QTMvkgLpAVpzBro8RX-WxPkA5bAS7pvTu4=.1df9e375-0025-45be-a7c1-52ec41ccf8c4@github.com>

On Wed, 4 Sep 2024 12:46:21 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Were you able to reproduce the original issue on RISC-V?
>
>> Were you able to reproduce the original issue on RISC-V?
> 
> Yeah. I can reproduce similar crash on linux-riscv64 platform running this new test as well.

Ok, I'll add riscv as one of the target platforms then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1743766814

From mcimadamore at openjdk.org  Wed Sep  4 13:15:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Sep 2024 13:15:19 GMT
Subject: RFR: 8338123: Linker crash when building a downcall handle with
 many arguments in x64
In-Reply-To: <p0QPoSFPn70tvHFPFy3lVGc3Ch2HVznRxj_-Z1GAiJ0=.8b46bf40-3191-4e84-a07c-54155581d1f0@github.com>
References: <p0QPoSFPn70tvHFPFy3lVGc3Ch2HVznRxj_-Z1GAiJ0=.8b46bf40-3191-4e84-a07c-54155581d1f0@github.com>
Message-ID: <vmdSoQjwDl5dWTOzo3k7wvkJhCpvlRg_LKFqyRF56vI=.858801d6-2cd3-4003-ab69-45e70a7bd92c@github.com>

On Tue, 3 Sep 2024 17:52:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> - Adjust downcall stub sizes based on latest version. (per method described in https://github.com/openjdk/jdk/pull/12908)
> - Beef up test for large stubs to also cover this particular case.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20842#pullrequestreview-2280166021

From duke at openjdk.org  Wed Sep  4 13:24:18 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 4 Sep 2024 13:24:18 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <ARQNL0KIDVbswpiixcTNXV3xvtMnr9lb-dShu1-DyVI=.ac8b296a-c453-48f4-aa8a-b569751d0afe@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <ARQNL0KIDVbswpiixcTNXV3xvtMnr9lb-dShu1-DyVI=.ac8b296a-c453-48f4-aa8a-b569751d0afe@github.com>
Message-ID: <2OFxQs--rrZkzpvaNtthK7syYkIos0rvOVazEA-p8zc=.91d29aee-dec8-4ff5-833d-cd98799dbeca@github.com>

On Wed, 4 Sep 2024 01:06:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> It looks good, but can you provide the codeSize before and after the change? For example, add the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to find `writeFrames` and see if this PR will change from less than 325 to greater than 325.
> 
> If codeSize changes from less than 325 to >325, the code that constructs the exception can be extracted to a separate method. String concatenation in java.base is implemented using StringBuilder, which will cause codeSize to expand.

I'm still trying to find a test which I can run that exercises this method. But in the meantime I did look at it with `javac` and the bytecode size of the method is 213 bytes, so I would expect it to be OK. If that's good enough then I'll leave it there, otherwise I'll keep trying to find test(s) which exercise this method.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329032795

From daniel.fuchs at oracle.com  Wed Sep  4 13:29:00 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 4 Sep 2024 14:29:00 +0100
Subject: Possible bug in jdk.naming.dns. I need guidance on how get
 someone smarter to look at it.
In-Reply-To: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
References: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
Message-ID: <ce5e1c8a-0ce9-45b3-88c0-d9c638397ced@oracle.com>

Hi Marko,

This is not the proper list for this kind of question:
I'm moving the discussion to core-libs-dev at openjdk.org.

There's definitely a bug here: that code should use
System.nanoTime() and not System.currentTimeMillis()
since the latter is not guaranteed to be monotonic.

It may not explain the issue you are observing, but
again, it may cause the timeout to punctually increase.

I have logged
https://bugs.openjdk.org/browse/JDK-8339538

I wonder if that has an impact on what you are observing.

best regards,

-- daniel

On 04/09/2024 13:50, Marko Bak?i? wrote:
> Hey there!
> 
> Sorry for coming here with a technical question, but I would appreciate 
> if you could point me in the right direction.
> 
> We experienced a bug in production a few times already and through 
> profiling we suspect it is an infinite loop here:
> https://github.com/openjdk/jdk/blob/master/src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java#L475 <https://github.com/openjdk/jdk/blob/master/src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java#L475>
> 
> I came here before opening a bug report, because I'm not sure I am 
> right. We haven't been able to reproduce the bug in a dev environment.
> Before spending much more time trying to reproduce this, I was hoping 
> someone smarter could give me a hint if this is even the right direction.
> 
> If no one here can help, I'd appreciate if you could point me in a 
> direction of somewhere where I could have a casual discussion about 
> this, or get some more eyes on this.
> 
> Thank you very much.
> 
> -- ?Marko
> 
> 
> 	
> 
> *Marko Bak?i?*
> 
> Software Engineer
> 
> 	
> 
> *E *Marko.Baksic at infobip.com
> 
> *M*
> 
> 	
> 
> *A *Utinjska 29A, 10000 Zagreb, Croatia
> 
> www.infobip.com<http://www.infobip.com>
> 
> <https://www.infobip.com/news/infobip-named-to-fast-companys-annual-list-of-the-worlds-most-innovative-companies-of-2024>
> 
> <https://www.facebook.com/infobip> 
> <https://www.linkedin.com/company/infobip> 
> <https://twitter.com/Infobip> 	<https://www.instagram.com/infobip/> 
> <https://www.youtube.com/channel/UCUPSTy53VecI5GIir3J3ZbQ>
> 
> *GSMA Associate Member*
> This email message and any attachments are intended solely for the use 
> of the addressee. If you are not the intended recipient, you are 
> prohibited from reading, disclosing, reproducing, distributing, 
> disseminating or otherwise using this transmission. If you have received 
> this message in error, please promptly notify the sender by reply email 
> and immediately delete this message from your system. This message and 
> any attachments may contain information that is confidential, privileged 
> or exempt from disclosure. Delivery of this message to any person other 
> than the intended recipient is not intended to waive any right or privilege.
> 


From swen at openjdk.org  Wed Sep  4 13:30:21 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 13:30:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
Message-ID: <TR4LCF3iRtPqDo0uL9uyUV_-K-9pfgCiTvcvbaU2pzg=.15aa6d0f-7eb3-4019-911b-17e2a6479888@github.com>

On Wed, 4 Sep 2024 12:01:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @cl4es 's suggestion

https://github.com/wenshao/jdk/actions/runs/10701158902/job/29667402594

runtime/cds/DeterministicDump.java

java.lang.RuntimeException: File content different at byte #4, b0 = -45, b1 = -22
	at DeterministicDump.compare(DeterministicDump.java:114)
	at DeterministicDump.doTest(DeterministicDump.java:66)
	at DeterministicDump.main(DeterministicDump.java:42)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)


macOS aarch64 build fails, but often works fine after re-running. Should I fix this?

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2329051019

From attila at openjdk.org  Wed Sep  4 13:43:33 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Wed, 4 Sep 2024 13:43:33 GMT
Subject: Integrated: 8325679: Optimize ArrayList subList sort
In-Reply-To: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
References: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
Message-ID: <Hq97uLuK9phBFYc5dMvKsbcOhJdxxLLL6y_qmYI6vuQ=.9fc228e1-0a6d-42cc-8856-c959b6d2e78c@github.com>

On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

This pull request has now been integrated.

Changeset: c7d15f1f
Author:    Attila Szegedi <attila at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7d15f1fe09e61c1e61ee253e7e3df4c2b9306a1
Stats:     17 lines in 2 files changed: 12 ins; 1 del; 4 mod

8325679: Optimize ArrayList subList sort

Reviewed-by: liach

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

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

From mdoerr at openjdk.org  Wed Sep  4 13:43:26 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Sep 2024 13:43:26 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <oHhJOAN_lqkj-AXZzUmk6nPcnrXSc6yaSqD3OLS2S_o=.0aab03c1-7621-4be3-85f1-aeafd6197ec9@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <oHhJOAN_lqkj-AXZzUmk6nPcnrXSc6yaSqD3OLS2S_o=.0aab03c1-7621-4be3-85f1-aeafd6197ec9@github.com>
Message-ID: <4htYDaThzZbOHDP1tq8hF60018HTq7Br-K9akXe8fwM=.0e17d325-896a-4f8d-aebe-3a3d91ae77b1@github.com>

On Wed, 4 Sep 2024 13:14:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add RISC-V as target platform

PPC64 code looks good. Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20479#pullrequestreview-2280263851

From redestad at openjdk.org  Wed Sep  4 13:46:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Sep 2024 13:46:24 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
Message-ID: <WjR7GHmsUhV5HjcC1Mx9IK8Iyjr3rjdQJiBAx8qSpRY=.28eac37d-83c0-44c8-8e3d-1a2be1aa8941@github.com>

On Wed, 4 Sep 2024 12:01:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @cl4es 's suggestion

There's an open bug on this test intermittently(?) failing in GHA: https://bugs.openjdk.org/browse/JDK-8338712 - so I think we can assume it's not something caused by something here.

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2329104670

From Marko.Baksic at infobip.com  Wed Sep  4 14:02:38 2024
From: Marko.Baksic at infobip.com (=?utf-8?B?TWFya28gQmFrxaFpxIc=?=)
Date: Wed, 4 Sep 2024 14:02:38 +0000
Subject: Possible bug in jdk.naming.dns. I need guidance on how get
 someone smarter to look at it.
In-Reply-To: <e059b25a-4981-43e5-bfe5-c1bb047d1f73@oracle.com>
References: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
 <e059b25a-4981-43e5-bfe5-c1bb047d1f73@oracle.com>
Message-ID: <DU0PR01MB9966DBCCA54B08D998D650DA859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>

Thank you Daniel.

The part that was suspicious to me is

```
int timeoutLeft = pktTimeout;
do {
??????...
??????timeoutLeft = pktTimeout - ((int) (end - start));
} while (timeoutLeft > MIN_TIMEOUT);
```

Here, timeoutLeft is not iteratively decreased, but is always derived from `pktTimeout`.
I can see a case where `timeoutLeft` never drops below `MIN_TIMEOUT` (this is the part where I'm not sure if I'm missing some deeper knowledge).

Kind regards,
-- Marko



[cid:Infobip_logo_vertical_signature_e28e13d2-255b-4571-a70c-8292f2d75c0b.png]

Marko Bak?i?

Software Engineer


E Marko.Baksic at infobip.com

M


A Utinjska 29A, 10000 Zagreb, Croatia

www.infobip.com<http://www.infobip.com>







________________________________
From: Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Wednesday, September 4, 2024 15:27
To: Marko Bak?i? <Marko.Baksic at infobip.com>
Subject: [EXTERNAL] Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Hi Marko,

This is not the proper list for this kind of question:
I'm moving the discussion to core-libs-dev at openjdk.org.

There's definitely a bug here: that code should use
System.nanoTime() and not System.currentTimeMillis()
since the latter is not guaranteed to be monotonic.

It may not explain the issue you are observing, but
again, it may cause the timeout to punctually increase.

I have logged
https://bugs.openjdk.org/browse/JDK-8339538

I wonder if that has an impact on what you are observing.

best regards,

-- daniel

On 04/09/2024 13:50, Marko Bak?i? wrote:
> Hey there!
>
> Sorry for coming here with a technical question, but I would appreciate
> if you could point me in the right direction.
>
> We experienced a bug in production a few times already and through
> profiling we suspect it is an infinite loop here:
> https://github.com/openjdk/jdk/blob/master/src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java#L475 <https://github.com/openjdk/jdk/blob/master/src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java#L475>
>
> I came here before opening a bug report, because I'm not sure I am
> right. We haven't been able to reproduce the bug in a dev environment.
> Before spending much more time trying to reproduce this, I was hoping
> someone smarter could give me a hint if this is even the right direction.
>
> If no one here can help, I'd appreciate if you could point me in a
> direction of somewhere where I could have a casual discussion about
> this, or get some more eyes on this.
>
> Thank you very much.
>
> -- ?Marko
>
>
>
>
> *Marko Bak?i?*
>
> Software Engineer
>
>
>
> *E *Marko.Baksic at infobip.com
>
> *M*
>
>
>
> *A *Utinjska 29A, 10000 Zagreb, Croatia
>
> www.infobip.com<http://www.infobip.com>
>
> <https://www.infobip.com/news/infobip-named-to-fast-companys-annual-list-of-the-worlds-most-innovative-companies-of-2024>
>
> <https://www.facebook.com/infobip>
> <https://www.linkedin.com/company/infobip>
> <https://twitter.com/Infobip>  <https://www.instagram.com/infobip/>
> <https://www.youtube.com/channel/UCUPSTy53VecI5GIir3J3ZbQ>
>
> *GSMA Associate Member*
> This email message and any attachments are intended solely for the use
> of the addressee. If you are not the intended recipient, you are
> prohibited from reading, disclosing, reproducing, distributing,
> disseminating or otherwise using this transmission. If you have received
> this message in error, please promptly notify the sender by reply email
> and immediately delete this message from your system. This message and
> any attachments may contain information that is confidential, privileged
> or exempt from disclosure. Delivery of this message to any person other
> than the intended recipient is not intended to waive any right or privilege.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/60a58161/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2551 bytes
Desc: Infobip_logo_vertical_signature_e28e13d2-255b-4571-a70c-8292f2d75c0b.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/60a58161/attachment-0001.png>

From duke at openjdk.org  Wed Sep  4 14:14:19 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 4 Sep 2024 14:14:19 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
Message-ID: <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>

On Wed, 4 Sep 2024 13:08:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> LGTM
> 
> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume getting rid of the `TreeMap` and `Integer` key allocations more than makes up for this, though. Do we have any JMH tests where `writeFrames` is a significant contributor we could check?

My expectation was that the short path of `DirectCodeBuilder` (where `context == this` and thus we directly return `lab.getBCI()`, which is a simple field getter) would be used in most, if not all, cases. If so, then this amounts to a fairly minimal and direct code path, thus I approached this as being an "obvious" (as opposed to theoretical) improvement.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329181476

From redestad at openjdk.org  Wed Sep  4 14:20:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Sep 2024 14:20:19 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
 <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
Message-ID: <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>

On Wed, 4 Sep 2024 14:12:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> If so, then this amounts to a fairly minimal and direct code path, thus I approached this as being an "obvious" (as opposed to theoretical) improvement.

I agree that it looks like the typical path is trivial, but I don't have the full picture to understand when we might do more complicated work here. It would be nice to have some reasonably realistic benchmark to lean on.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329196875

From alexey.ivanov at oracle.com  Wed Sep  4 14:31:27 2024
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Wed, 4 Sep 2024 15:31:27 +0100
Subject: Possible bug in jdk.naming.dns. I need guidance on how get
 someone smarter to look at it.
In-Reply-To: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
References: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
Message-ID: <9464df24-7b3f-4834-93fb-6f1b68f7c4a1@oracle.com>

Hello Marko,

core-libs-dev at openjdk.org is better suited for this kind of question.

You can submit a bug using bugreport.java.com with all the details you have.


Regards,
Alexey

On 2024-09-04 13:50, Marko Bak?i? wrote:
> Hey there!
>
> Sorry for coming here with a technical question, but I would 
> appreciate if you could point me in the right direction.
>
> We experienced a bug in production a few times already and through 
> profiling we suspect it is an infinite loop here:
> https://github.com/openjdk/jdk/blob/master/src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java#L475
>
> I came here before opening a bug report, because I'm not sure I am 
> right. We haven't been able to reproduce the bug in a dev environment.
> Before spending much more time trying to reproduce this, I was hoping 
> someone smarter could give me a hint if this is even the right direction.
>
> If no one here can help, I'd appreciate if you could point me in a 
> direction of somewhere where I could have a casual discussion about 
> this, or get some more eyes on this.
>
> Thank you very much.
>
> -- ?Marko
>
>
> 	
>
> *Marko Bak?i?*
>
> Software Engineer
>
> 	
>
> *E *Marko.Baksic at infobip.com
>
> *M*
>
> 	
>
> *A *Utinjska 29A, 10000 Zagreb, Croatia
>
> www.infobip.com<http://www.infobip.com>
>
> <https://www.infobip.com/news/infobip-named-to-fast-companys-annual-list-of-the-worlds-most-innovative-companies-of-2024>
>
> <https://www.facebook.com/infobip> 
> <https://www.linkedin.com/company/infobip> 
> <https://twitter.com/Infobip> 	<https://www.instagram.com/infobip/> 
> <https://www.youtube.com/channel/UCUPSTy53VecI5GIir3J3ZbQ>
>
> *GSMA Associate Member*
> This email message and any attachments are intended solely for the use 
> of the addressee. If you are not the intended recipient, you are 
> prohibited from reading, disclosing, reproducing, distributing, 
> disseminating or otherwise using this transmission. If you have 
> received this message in error, please promptly notify the sender by 
> reply email and immediately delete this message from your system. This 
> message and any attachments may contain information that is 
> confidential, privileged or exempt from disclosure. Delivery of this 
> message to any person other than the intended recipient is not 
> intended to waive any right or privilege.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/e87a49d9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2551 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/e87a49d9/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19649 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/e87a49d9/image-0003.png>

From liach at openjdk.org  Wed Sep  4 14:39:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 14:39:20 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
 <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
Message-ID: <9uqek4T0Ks7ljwr-ytl4zsuXgsIgtwC3-08Rgk21Z0A=.08c25ddd-76d9-44f5-8566-a72d907c0822@github.com>

On Wed, 4 Sep 2024 14:12:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> LGTM
>> 
>> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume getting rid of the `TreeMap` and `Integer` key allocations more than makes up for this, though. Do we have any JMH tests where `writeFrames` is a significant contributor we could check?
>
>> LGTM
>> 
>> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume getting rid of the `TreeMap` and `Integer` key allocations more than makes up for this, though. Do we have any JMH tests where `writeFrames` is a significant contributor we could check?
> 
> My expectation was that the short path of `DirectCodeBuilder` (where `context == this` and thus we directly return `lab.getBCI()`, which is a simple field getter) would be used in most, if not all, cases. If so, then this amounts to a fairly minimal and direct code path, thus I approached this as being an "obvious" (as opposed to theoretical) improvement.

@dmlloyd I think we might need a benchmark that uses `ClassFile.of(StackMapsOption.DROP_STACK_MAPS)` to build a class with method with code, and supply the stack maps to generate. That is the best way to measure the gains from this patch. (Something like what we do in ProxyGenerator, but proxy generation has too many uncertainties)

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329244951

From alanb at openjdk.org  Wed Sep  4 14:41:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Sep 2024 14:41:19 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information
In-Reply-To: <2lRpwwXrzplICv8dlaZ1D0CIx2BADRCw0b3R-qAOjlw=.471d4387-281f-4b94-a209-21c310963ce1@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <OTdj0y0Yb4zgFUVBRJtKsdpbqsqquDS3oIgBkCaTeZs=.e83188b7-bc65-44d3-b907-62425e0d422f@github.com>
 <UJ90n2n2eCJXBLr1KOC1oUs17lFaKJmO4DbbjmlJDH8=.476fcc46-111a-4333-8914-e627b2203910@github.com>
 <Up6nQin3_Epxqe8MYRVtvOowIcc7u89vaHB6VMImbwk=.71804979-9aa0-49b8-baec-c6fa510d9e43@github.com>
 <HpSwVfxhjQCqVF2dHLv9JVvw0p5WZvmu23E-xZvp0NM=.ae3bd745-7c57-4cc7-b928-83a63269bf18@github.com>
 <2lRpwwXrzplICv8dlaZ1D0CIx2BADRCw0b3R-qAOjlw=.471d4387-281f-4b94-a209-21c310963ce1@github.com>
Message-ID: <E1hlpRECOJ6YYmhnmSU9_L3GWzIRwFtXasnPt-d2PLg=.3117f920-9920-4234-bd57-730367dc521d@github.com>

On Wed, 4 Sep 2024 12:22:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi , my guess is too that it is the second call. In case we want to go for a loop, should we have a maximum number of retry operations like 10 or 100 ? Another option might be to always make the buffer a little bigger (how much can be discussed) and use the larger buffer to account for some increase in the number of processes.

It may have to loop indefinitely to allow for cases where something else is forking 100+ processes. In practise I assume it will only need to retry once or twice. You could combine the approaches so that you allocate a bit more than is required to take account of a few processes created in the window between the two calls to sysctl.

So I think we should just do this. We still need to figure out the exception when sys call fails for some other reason.

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2329251128

From liach at openjdk.org  Wed Sep  4 14:47:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 14:47:19 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <hdWsZujYEh_hLDaTruBjNYGCkudvBDzfY0NweL3f5Uo=.f1f26ff7-b71d-4a55-ab5c-291e67299d45@github.com>

On Wed, 4 Sep 2024 09:09:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 49:

> 47: 
> 48:     // MISMATCH_NATIVE_THRESHOLD must be a power of two and should be greater than 2^3
> 49:     private static final long MISMATCH_NATIVE_THRESHOLD = 1 << 20;

Should we allow toggling this threshold via properties to allow using vectorizedMismatchLargeForBytes for small lengths, such as for testing or debugging?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1743938437

From duke at openjdk.org  Wed Sep  4 14:50:21 2024
From: duke at openjdk.org (fitzsim)
Date: Wed, 4 Sep 2024 14:50:21 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <P9dPj52o09OUL2gkttLZHH-Z8dovmfNVSkhX_MU-cp8=.28897a1c-0768-43a8-9a68-d562eb22b907@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
 <P9dPj52o09OUL2gkttLZHH-Z8dovmfNVSkhX_MU-cp8=.28897a1c-0768-43a8-9a68-d562eb22b907@github.com>
Message-ID: <M4P9PjPGMdxBJVIQHw9ug3U3Ew_VX_eGMaPbdfPefuc=.3f4b546b-5ceb-4572-9d18-9220b2b5743f@github.com>

On Wed, 4 Sep 2024 11:33:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions
>
> test/hotspot/jtreg/runtime/BootClassAppendProp/BootClassPathZipFileCreator.java line 1:
> 
>> 1: /*
> 
> Shouldn't this be in `test/jdk/java/util/zip`?

OK.  I was not sure the best place for them, because they test the handling of Zip files on the `HotSpot` bootstrap class path.  But the creator class could be reused for other Zip tests, so `test/jdk/java/util/zip` is probably better.  I will move both the creator and the test files to `test/jdk/java/util/zip`.  The creator class could/should maybe be named more generically, but as a first step I will just move the files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19678#discussion_r1743944490

From daniel.fuchs at oracle.com  Wed Sep  4 14:59:22 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 4 Sep 2024 15:59:22 +0100
Subject: Possible bug in jdk.naming.dns. I need guidance on how get
 someone smarter to look at it.
In-Reply-To: <DU0PR01MB9966DBCCA54B08D998D650DA859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
References: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
 <e059b25a-4981-43e5-bfe5-c1bb047d1f73@oracle.com>
 <DU0PR01MB9966DBCCA54B08D998D650DA859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
Message-ID: <bb5542ce-26db-4d08-bbba-1106a3769697@oracle.com>

On 04/09/2024 15:02, Marko Bak?i? wrote:
> Thank you Daniel.
> 
> The part that was suspicious to me is
> 
> ```
> int timeoutLeft = pktTimeout;
> do {
> ??????...
> ??????timeoutLeft = pktTimeout - ((int) (end - start));
> } while (timeoutLeft > MIN_TIMEOUT);
> ```
> 
> Here, timeoutLeft is not iteratively decreased, but is always derived 
> from `pktTimeout`.
> I can see a case where `timeoutLeft` never drops below `MIN_TIMEOUT` 
> (this is the part where I'm not sure if I'm missing some deeper knowledge).

Indeed - good observation!

-- daniel



From duke at openjdk.org  Wed Sep  4 15:02:23 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 4 Sep 2024 15:02:23 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
 <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
 <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>
Message-ID: <eu1xzi3NAR0iqFb0yDBjSNO0hBynqZGfTeFDzHb_ATs=.4ba77f9c-4af7-4149-b8a5-c6ecc0b20619@github.com>

On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > If so, then this amounts to a fairly minimal and direct code path, thus I approached this as being an "obvious" (as opposed to theoretical) improvement.
> 
> I agree that it looks like the typical path is trivial, but I don't have the full picture to understand when we might do more complicated work here. It would be nice to have some reasonably realistic benchmark to lean on.

I wrote a trivial scratch file which exercises the code using a regular code builder and it did indeed use the expected path, FWIW. I'm honestly not sure what (if any) valid circumstances would cause this particular code to run on a label whose contest is not the code builder itself, so if anyone has any thoughts on that, please share.

> @dmlloyd I think we might need a benchmark that uses `ClassFile.of(StackMapsOption.DROP_STACK_MAPS)` to build a class with method with code, and supply the stack maps to generate. That is the best way to measure the gains from this patch. (Something like what we do in ProxyGenerator, but proxy generation has too many uncertainties)

I'll see if I can get the benchmarks in `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there may be one or more of them which would reach into this code.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329302010

From duke at openjdk.org  Wed Sep  4 15:03:03 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 4 Sep 2024 15:03:03 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v6]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <jTtqCCE1nF6_iXI6ahkmAKmDzdjVJKlfjnLxCCj6dyA=.028f3aec-62ce-42bb-b18d-9a0b326f8552@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 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 'openjdk:master' into patchLeftShift
 - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
 - Merge branch 'openjdk:master' into patchLeftShift
 - Restructuring tests
   
   Removed the benchmark  and rewrote the test class for MBI.leftShift() in order to use JUnit.
 - Code more clear
 - Tests changes
 - Merge branch 'openjdk:master' into patchLeftShift
 - Removed trailing whitespace
 - MutableBigInteger.leftShift(int) optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/87474ee9..df35072c

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

  Stats: 4265 lines in 192 files changed: 2497 ins; 660 del; 1108 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

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

From duke at openjdk.org  Wed Sep  4 15:04:25 2024
From: duke at openjdk.org (fitzsim)
Date: Wed, 4 Sep 2024 15:04:25 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <P9dPj52o09OUL2gkttLZHH-Z8dovmfNVSkhX_MU-cp8=.28897a1c-0768-43a8-9a68-d562eb22b907@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
 <P9dPj52o09OUL2gkttLZHH-Z8dovmfNVSkhX_MU-cp8=.28897a1c-0768-43a8-9a68-d562eb22b907@github.com>
Message-ID: <tdnmoeNII4T96_epKN9987gCCkrUpkOesYIdYK6qWMQ=.8c7e4ba8-7f37-4a08-b693-9e83c9884673@github.com>

On Wed, 4 Sep 2024 11:45:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions
>
> Not an expert in this area, so just a drive-by review.

Thank you for reviewing @jerboaa.  I will work on implementing your suggestions.

> test/hotspot/jtreg/runtime/BootClassAppendProp/BootClassPathZipFileCreator.java line 76:
> 
>> 74:             env.put("forceZIP64End", "true");
>> 75:         }
>> 76:         Path zip = Paths.get(System.getProperty("user.dir"), type + ".zip");
> 
> Should we use `test.classes` (i.e. `System.getProperty("test.classes", System.getProperty("user.dir")`) dir for those transient files?

Will do, see below.

> test/hotspot/jtreg/runtime/BootClassAppendProp/BootClassPathZipFileTest.java line 49:
> 
>> 47:         // the ZIP file not existing is the same as the ZIP file not being
>> 48:         // readable, that is, ClassNotFoundException on CLASS_NAME.
>> 49:         Path zipPath = Paths.get(System.getProperty("user.dir"), args[0]);
> 
> `test.classes` here as well.

I re-read the jtreg tag-spec documentation about this and I agree this is the most appropriate place for these files.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2329307051
PR Review Comment: https://git.openjdk.org/jdk/pull/19678#discussion_r1743966886
PR Review Comment: https://git.openjdk.org/jdk/pull/19678#discussion_r1743966979

From aleksej.efimov at oracle.com  Wed Sep  4 15:29:27 2024
From: aleksej.efimov at oracle.com (Aleksei Efimov)
Date: Wed, 4 Sep 2024 15:29:27 +0000
Subject: Possible bug in jdk.naming.dns. I need guidance on how get
 someone smarter to look at it.
In-Reply-To: <bb5542ce-26db-4d08-bbba-1106a3769697@oracle.com>
References: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
 <e059b25a-4981-43e5-bfe5-c1bb047d1f73@oracle.com>
 <DU0PR01MB9966DBCCA54B08D998D650DA859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
 <bb5542ce-26db-4d08-bbba-1106a3769697@oracle.com>
Message-ID: <IA0PR10MB7304155FA7DBB0DB4301DDF7EC9C2@IA0PR10MB7304.namprd10.prod.outlook.com>

Thank you, Marko - it's an excellent catch! Indeed, we have a bug in a code that updates the left timeout. And yes, we should use nanoTime for measuring elapsed time. I will work on a fix for both issues and will try to create a test for the left timeout update scenario.

- Aleksei
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: 04 September 2024 3:59 PM
To: Marko Bak?i? <Marko.Baksic at infobip.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

On 04/09/2024 15:02, Marko Bak?i? wrote:
> Thank you Daniel.
>
> The part that was suspicious to me is
>
> ```
> int timeoutLeft = pktTimeout;
> do {
> ??????...
> ??????timeoutLeft = pktTimeout - ((int) (end - start));
> } while (timeoutLeft > MIN_TIMEOUT);
> ```
>
> Here, timeoutLeft is not iteratively decreased, but is always derived
> from `pktTimeout`.
> I can see a case where `timeoutLeft` never drops below `MIN_TIMEOUT`
> (this is the part where I'm not sure if I'm missing some deeper knowledge).

Indeed - good observation!

-- daniel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240904/26bb8837/attachment.htm>

From liach at openjdk.org  Wed Sep  4 15:30:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 15:30:26 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <eu1xzi3NAR0iqFb0yDBjSNO0hBynqZGfTeFDzHb_ATs=.4ba77f9c-4af7-4149-b8a5-c6ecc0b20619@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
 <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
 <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>
 <eu1xzi3NAR0iqFb0yDBjSNO0hBynqZGfTeFDzHb_ATs=.4ba77f9c-4af7-4149-b8a5-c6ecc0b20619@github.com>
Message-ID: <z7beP8EO_fRFv07e-s1r6BRoubkPfPeg5M9UU96zcJ4=.48725449-8b90-4d5c-b193-15178ce83245@github.com>

On Wed, 4 Sep 2024 14:59:50 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> I'll see if I can get the benchmarks in `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there may be one or more of them which would reach into this code.

Just checked; no benchmark is currently supplying a manual `StackMapTableAttribute` to class building, so new benchmark is required. Fyi this is only used by manual stack map building; internally we use a `StackMapGenerator.stackMapTableAttribute()` which is an ad-hoc attribute for writing only.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329375973

From nbenalla at openjdk.org  Wed Sep  4 15:32:41 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Sep 2024 15:32:41 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v2]
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <5OcOD6zYMPs6902_xjt3j6gvafZO-JGAS-4yCkk472c=.ae91898c-b3c0-4f85-9230-289983b83e88@github.com>

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
 - Tiny changes, some variable renames
 - Changes after JDK-8339214
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
 - - Passes all tests, a lot of comments for future work and questions
   
   - Added (C)
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
 - drop unused test file
 - Add more null checks, added some todos for methods that need to be revisited.
   
   Some tests need to be updated if we want to integrate this change
   
   use regex to switch Object.require non null with the static import.
   Just for nicer syntax
 - Merge remote-tracking branch 'upstream/master' into classfile-nulls
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
 - add requiresnonnull where necessary
 - ... and 2 more: https://git.openjdk.org/jdk/compare/6f8714ee...cf75c679

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

Changes: https://git.openjdk.org/jdk/pull/20556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20556&range=01
  Stats: 1458 lines in 85 files changed: 1388 ins; 20 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/20556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20556/head:pull/20556

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

From jwaters at openjdk.org  Wed Sep  4 15:48:21 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Sep 2024 15:48:21 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <UGHq6xsXL3ev34I1QRTbyMkP8qIcub1yxAQJwN6whAA=.229c8d96-a5b1-47a6-aeaa-ac74151a63d3@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/20841#pullrequestreview-2280616851

From asotona at openjdk.org  Wed Sep  4 15:51:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Sep 2024 15:51:20 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
Message-ID: <ArjXYcoXRqlpLODp4LAeQK7vEfA0q4WZOyMS58JiYyw=.5ff6ad1a-5a8e-431a-99b5-c15e2963ac58@github.com>

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: reject duplicate stack map entries

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20841#pullrequestreview-2280625822

From duke at openjdk.org  Wed Sep  4 16:09:19 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 4 Sep 2024 16:09:19 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <z7beP8EO_fRFv07e-s1r6BRoubkPfPeg5M9UU96zcJ4=.48725449-8b90-4d5c-b193-15178ce83245@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
 <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
 <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>
 <eu1xzi3NAR0iqFb0yDBjSNO0hBynqZGfTeFDzHb_ATs=.4ba77f9c-4af7-4149-b8a5-c6ecc0b20619@github.com>
 <z7beP8EO_fRFv07e-s1r6BRoubkPfPeg5M9UU96zcJ4=.48725449-8b90-4d5c-b193-15178ce83245@github.com>
Message-ID: <QfL3bVG6gfFoBs6Ic4YMFgpWhDjSfNehsjX1fiBMkGg=.5fd4161d-9591-4aa1-8bc4-73e32e5b612e@github.com>

On Wed, 4 Sep 2024 15:27:40 GMT, Chen Liang <liach at openjdk.org> wrote:

> > I'll see if I can get the benchmarks in `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there may be one or more of them which would reach into this code.
> 
> Just checked; no benchmark is currently supplying a manual `StackMapTableAttribute` to class building, so new benchmark is required. Fyi this is only used by manual stack map building; internally we use a `StackMapGenerator.stackMapTableAttribute()` which is an ad-hoc attribute for writing only.

OK. Is this critical for merging the PR? I could likely come up with something but it'd have to wait a bit due to other priorities (this was meant to be a quick Friday task ?).

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329466089

From amitkumar at openjdk.org  Wed Sep  4 16:49:26 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Sep 2024 16:49:26 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <lgttiVGFH9LgYzOGqlvbjJyimVAGjzMqcx56gQNS3pE=.433730d3-589a-488d-8bf0-225ff181f292@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <lgttiVGFH9LgYzOGqlvbjJyimVAGjzMqcx56gQNS3pE=.433730d3-589a-488d-8bf0-225ff181f292@github.com>
Message-ID: <XbGJQepek4rosScV7wy6rAsmHdxKD-THK3HLOT35afQ=.4bd3a95d-c30d-4a4c-8c14-eaed8ec48080@github.com>

On Wed, 4 Sep 2024 10:00:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add RISC-V as target platform
>
> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062:
> 
>> 3060:     StubCodeMark mark(this, "StubRoutines", "upcall_stub_load_target");
>> 3061:     address start = __ pc();
>> 3062:     __ save_return_pc();
> 
> @offamitkumar: Is saving and restoring the return_pc needed? Isn't in preserved by load_heap_oop?

I looked into it, but couldn't find out. But I remove the `save_return_pc` & `restore_return_pc` and everything seems fine. So maybe we can remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1744116982

From amitkumar at openjdk.org  Wed Sep  4 16:49:27 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Sep 2024 16:49:27 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <XbGJQepek4rosScV7wy6rAsmHdxKD-THK3HLOT35afQ=.4bd3a95d-c30d-4a4c-8c14-eaed8ec48080@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <lgttiVGFH9LgYzOGqlvbjJyimVAGjzMqcx56gQNS3pE=.433730d3-589a-488d-8bf0-225ff181f292@github.com>
 <XbGJQepek4rosScV7wy6rAsmHdxKD-THK3HLOT35afQ=.4bd3a95d-c30d-4a4c-8c14-eaed8ec48080@github.com>
Message-ID: <xKd0prUFEvSHZOQojM578jthD0VYbsF0lKt5Hcn40iQ=.917ef4a3-c357-4e5d-b2e3-d71dbc24444c@github.com>

On Wed, 4 Sep 2024 16:45:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062:
>> 
>>> 3060:     StubCodeMark mark(this, "StubRoutines", "upcall_stub_load_target");
>>> 3061:     address start = __ pc();
>>> 3062:     __ save_return_pc();
>> 
>> @offamitkumar: Is saving and restoring the return_pc needed? Isn't in preserved by load_heap_oop?
>
> I looked into it, but couldn't find out. But I remove the `save_return_pc` & `restore_return_pc` and everything seems fine. So maybe we can remove it.

Tier1 test are fine with/without "saving & restoring" return_pc;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1744117640

From liach at openjdk.org  Wed Sep  4 16:51:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 16:51:23 GMT
Subject: RFR: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations [v2]
In-Reply-To: <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
 <c_NkvGhsjBq1LjpyYdGL4cUgz31s5ER5hjN8LQSfz7k=.a7f56e5a-7b68-4f2e-bc7c-034f9ee6cee8@github.com>
 <rCti-cTwBiRBQ4aKp2eRYew3zoBuh4Odgh2xHVzDl0Y=.b912fce5-e094-41bc-8519-fed2a72b6fa4@github.com>
 <b5dD6e0wOBdnvDqE662KcAPObjXE7azPUrOKP7WSjD4=.f0c251bb-38c8-4bc1-82c7-888d64d05fa3@github.com>
 <QW87SRzlmMuEQGL_VPDpCf5JCTz3_G6GNL4wh-ZT1A8=.f56ac873-853a-4e7c-add2-8cef274f4806@github.com>
Message-ID: <oMk3Gz14GABzXIKrDL5CvU8p-dod1V1_D-cJZMnato8=.86a0a053-3c26-4dc4-820f-6c8330cf09c1@github.com>

On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> LGTM
>>> 
>>> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume getting rid of the `TreeMap` and `Integer` key allocations more than makes up for this, though. Do we have any JMH tests where `writeFrames` is a significant contributor we could check?
>> 
>> My expectation was that the short path of `DirectCodeBuilder` (where `context == this` and thus we directly return `lab.getBCI()`, which is a simple field getter) would be used in most, if not all, cases. If so, then this amounts to a fairly minimal and direct code path, thus I approached this as being an "obvious" (as opposed to theoretical) improvement.
>
>> If so, then this amounts to a fairly minimal and direct code path, thus I approached this as being an "obvious" (as opposed to theoretical) improvement.
> 
> I agree that it looks like the typical path is trivial, but I don't have the full picture to understand when we might do more complicated work here. It would be nice to have some reasonably realistic benchmark to lean on.

@cl4es would love to see a benchmark, but from CF API developer's perspective, this change alone should be good enough. TreeMap is like a linked list, aside from the reduction of allocations, this array also has a locality advantage; so things should be fine. Except this won't manifest itself much, maybe a tiny little bit for ProxyGenerator.

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

PR Comment: https://git.openjdk.org/jdk/pull/20841#issuecomment-2329542210

From duke at openjdk.org  Wed Sep  4 16:51:24 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 4 Sep 2024 16:51:24 GMT
Subject: Integrated: 8339492: StackMapDecoder::writeFrames makes lots of
 allocations
In-Reply-To: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
References: <KEVQozRzm6mrss0UirZACP0vm75Chv59GFAeDhSuAi0=.9999fd2e-e343-49ba-8519-b9fa01e3b6c9@github.com>
Message-ID: <0ILvT1otO2OGpVF4P3u0lSIH3HPGt67DlkJ0-jmgaf4=.3e9d3d31-04d1-4aa4-83fc-7d0d052a01d7@github.com>

On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this change, which reduces the number of allocations in `StackMapDecoder::writeFrames` by using a sorted array instead of a `TreeMap<Integer, ...>` to sort and uniquify entries before writing. It also adds a validation missed by the original implementation.

This pull request has now been integrated.

Changeset: 433f6d8a
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7
Stats:     17 lines in 1 file changed: 8 ins; 1 del; 8 mod

8339492: StackMapDecoder::writeFrames makes lots of allocations

Reviewed-by: liach, redestad, jwaters, asotona

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

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

From mdoerr at openjdk.org  Wed Sep  4 17:07:20 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Sep 2024 17:07:20 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <xKd0prUFEvSHZOQojM578jthD0VYbsF0lKt5Hcn40iQ=.917ef4a3-c357-4e5d-b2e3-d71dbc24444c@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <lgttiVGFH9LgYzOGqlvbjJyimVAGjzMqcx56gQNS3pE=.433730d3-589a-488d-8bf0-225ff181f292@github.com>
 <XbGJQepek4rosScV7wy6rAsmHdxKD-THK3HLOT35afQ=.4bd3a95d-c30d-4a4c-8c14-eaed8ec48080@github.com>
 <xKd0prUFEvSHZOQojM578jthD0VYbsF0lKt5Hcn40iQ=.917ef4a3-c357-4e5d-b2e3-d71dbc24444c@github.com>
Message-ID: <snjODYeKBUua5UmNQrNxteFUdQp_0w5ehUCU29T2lBU=.73abe450-2870-4f4d-bd0d-d464278daf26@github.com>

On Wed, 4 Sep 2024 16:45:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> I looked into it, but couldn't find out. But I remove the `save_return_pc` & `restore_return_pc` and everything seems fine. So maybe we can remove it.
>
> Tier1 test are fine with/without "saving & restoring" return_pc;

I found it: https://github.com/openjdk/jdk/blob/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7/src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp#L238
Called here:
https://github.com/openjdk/jdk/blob/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7/src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp#L115
Other GCs with load barriers are not implemented, so the save&restore code is redundant.
The stub is frameless and only needs the save&restore code when calling C.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1744140160

From dhanalla at openjdk.org  Wed Sep  4 17:22:19 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Wed, 4 Sep 2024 17:22:19 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <gmsFUzbuvV3NXS-4uG4eC3LRixJfcQVjwSpZyQJKV58=.8620392a-5401-47bb-b292-be0aec2623ec@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <gmsFUzbuvV3NXS-4uG4eC3LRixJfcQVjwSpZyQJKV58=.8620392a-5401-47bb-b292-be0aec2623ec@github.com>
Message-ID: <WPcJUdp8MJrZScCS5hak4gfP5Rky2lKagYChVfhMlpM=.bd99cd7b-720c-4fb1-9f51-26d34e2e412e@github.com>

On Wed, 21 Aug 2024 09:07:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi,
> 
> From the linked doc: "When calling this function from a process running as SYSTEM it will return the path C:\Windows\SystemTemp, which is inaccessible to non-SYSTEM processes. For non-SYSTEM processes, GetTempPath2 will behave the same as GetTempPath."
> 
> If SYSTEM and regular user processes have a different temp path, and we change temp as it's known to the attach api, they will have a different hsperfdata_username locations.
> 
> Then does the attach api only find processes that are of the same category (SYSTEM vs non-SYSTEM)? e.g. "jps" for a user does not show SYSTEM processes?
> 
> SYSTEM is not the "Administrator" user, so it's not going to be a very common problem, but if a Java process run as a SYSTEM then it could be an issue (is that possible?).
> 
> And if Java can't be run as a SYSTEM task, then the doc states GetTempPath2 will behave the same as GetTempPath.

Thanks @kevinjwalls for reviewing this PR
The behavior has not changed; the old API GetTempPath also returns different temporary paths for SYSTEM and non-SYSTEM accounts, similar to the new API GetTempPath2.

For SYSTEM accounts:
GetTempPath: C:\WINDOWS\TEMP\
GetTempPath2: C:\WINDOWS\SystemTemp\

For non-SYSTEM accounts:
GetTempPath: C:\Users\\<user>\AppData\Local\Temp\
GetTempPath2: C:\Users\\<user>\AppData\Local\Temp\

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

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2329598028

From redestad at openjdk.org  Wed Sep  4 17:33:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Sep 2024 17:33:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
Message-ID: <jbJVfspS9p3Ml3C4DVZPhfpt0KEZ9I5C8TG4BcxOXuA=.ed6ce3e9-c85a-485f-8895-7fd159911ada@github.com>

On Wed, 4 Sep 2024 12:01:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @cl4es 's suggestion

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2280857373

From sgehwolf at openjdk.org  Wed Sep  4 17:46:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Sep 2024 17:46:00 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v9]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
> - [x] GHA

Severin Gehwolf 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:

 - Adapt JDK-8339148
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Fix comment of WB::host_cpus()
 - Handle non-root + CGv2
 - Add nested hierarchy to test framework
 - Revert "Add root check for SystemdMemoryAwarenessTest.java"
   
   This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
 - Add root check for SystemdMemoryAwarenessTest.java
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - ... and 7 more: https://git.openjdk.org/jdk/compare/29f3dd39...30f32d22

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19530/files
  - new: https://git.openjdk.org/jdk/pull/19530/files/cf49a96e..30f32d22

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

  Stats: 2593 lines in 119 files changed: 1994 ins; 169 del; 430 mod
  Patch: https://git.openjdk.org/jdk/pull/19530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530

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

From liach at openjdk.org  Wed Sep  4 18:10:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 18:10:20 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]
In-Reply-To: <MBSO7fpy1YdBjhR7dyi3uM0ZtvA9wSUFINMM2gE4530=.09337a2e-dca1-4ff2-a73b-59caf5176a20@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Vh_-tusSGBtVlbYyOGCILsZA_QADI68-42pwveH9-3Y=.e4b46baf-d21e-49e1-ae5e-3f3b63293858@github.com>
 <uDPrgErrMm6NSOXAjweXj3bMJuoyOJUuSeAU6Fj6ymM=.de390be1-2cde-4c3d-b788-0cb8994f8820@github.com>
 <lCBt_zkM7e3Qb_Egv7Cfp78qz3diYoq3wZ0yNGPTaQE=.2629992d-44bd-42bb-a798-45394626fc51@github.com>
 <MBSO7fpy1YdBjhR7dyi3uM0ZtvA9wSUFINMM2gE4530=.09337a2e-dca1-4ff2-a73b-59caf5176a20@github.com>
Message-ID: <SdbHi_LtSRmDIywfmXATS21d0TXNiHvyxvSPWiPyNlE=.10d736ad-79ab-4e31-96da-8c227e006fb3@github.com>

On Wed, 4 Sep 2024 11:54:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Let?s not add this, because normal logic should not pay the cost for abnormal logic
>
> Agreed in principle, but not sure the cost of this quick fail-fast sanity test would be noticeable?

If we add this, we should add this before the `countNonZeroAscii` call. Let's leave it as-is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1744222112

From liach at openjdk.org  Wed Sep  4 18:13:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 18:13:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
Message-ID: <YOeL19YWRocDvDhcVQ581gwBNsls5E6YLPCzdjNHPFY=.dfe0420d-5658-4c42-8ffe-963508b2cb4a@github.com>

On Wed, 4 Sep 2024 12:01:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @cl4es 's suggestion

test/jdk/java/lang/String/CountNonZeroAscii.java line 35:

> 33:  * @modules java.base/jdk.internal.access
> 34:  * @summary test latin1 String countNonZeroAscii
> 35:  * @run testng/othervm -XX:+CompactStrings CountNonZeroAscii

You are using the `testng` driver for a `main` test. I can probably fix it quickly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1744224282

From bpb at openjdk.org  Wed Sep  4 19:03:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Sep 2024 19:03:32 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v5]
In-Reply-To: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
Message-ID: <hiK95zMILWrBld8Vrb-JhiZCUsw94ajSUYR3H0NHUOE=.4e0d3784-da85-4ea3-8a1c-42339651f1de@github.com>

> Return the final path derived from the string returned by `canonicalize0()`.

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

  8003887: Use Assumptions.assumeTrue() and other and other cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20801/files
  - new: https://git.openjdk.org/jdk/pull/20801/files/44bed9ff..796a634f

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

  Stats: 26 lines in 2 files changed: 2 ins; 9 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20801/head:pull/20801

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

From bpb at openjdk.org  Wed Sep  4 19:03:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Sep 2024 19:03:34 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v4]
In-Reply-To: <yV3uxBYNrAKb38t7rXgcltwfDE9cmFqzmOZumqtvIuA=.9a332106-2263-4541-b7d5-7adeda68d546@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <CK0vFuzSbT4wE_mj8yuW9n9YEqJX19YgEI3De-cZwC0=.9cdda155-207c-43db-8cbc-3702b03c1506@github.com>
 <yV3uxBYNrAKb38t7rXgcltwfDE9cmFqzmOZumqtvIuA=.9a332106-2263-4541-b7d5-7adeda68d546@github.com>
Message-ID: <kusuOSL54-jN3YgSrcmJaYGDIKqHQfNpK7dw1vP4l5Q=.087f0a4e-1e2a-479f-a616-a732c2a8a142@github.com>

On Wed, 4 Sep 2024 08:40:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8003887: Test getCanonicalPath when the path contains links
>
> src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 347:
> 
>> 345: 
>> 346:     if (rv == NULL && !(*env)->ExceptionCheck(env)) {
>> 347:         JNU_ThrowIOExceptionWithLastError(env, "Bad pathname"); // XXX message?
> 
> That "not useful" exception message is probably okay because this is what canonicalize has always used.

Removed "XXX" note in 796a634.

> test/jdk/java/io/File/GetCanonicalPath.java line 129:
> 
>> 127:     }
>> 128: 
>> 129:     private static Path createPath(String pathname) throws IOException {
> 
> This method creates a File, returning a Path to the file, so maybe better method name needed here.

Changed to `createFile` and added a one line comment in 796a634.

> test/jdk/java/io/File/GetCanonicalPath.java line 135:
> 
>> 133:     }
>> 134: 
>> 135:     private static boolean testLinks = true;
> 
> It might be clearer to replace this with supportsLinks and have the tests Assumptions.asserTrue(supportsLinks) so they will be skipped when not supported.

Changed `testLinks` to `supportsLinks` and added use of `Assumptions.assumeTrue(supportsLinks, linkMessage)` in 796a634.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1744279977
PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1744280622
PR Review Comment: https://git.openjdk.org/jdk/pull/20801#discussion_r1744281779

From alanb at openjdk.org  Wed Sep  4 19:09:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Sep 2024 19:09:20 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v5]
In-Reply-To: <hiK95zMILWrBld8Vrb-JhiZCUsw94ajSUYR3H0NHUOE=.4e0d3784-da85-4ea3-8a1c-42339651f1de@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
 <hiK95zMILWrBld8Vrb-JhiZCUsw94ajSUYR3H0NHUOE=.4e0d3784-da85-4ea3-8a1c-42339651f1de@github.com>
Message-ID: <4Gn8vhsZwc6gTqTgbR35SMawqNXgGXCEPTdjcf91yEk=.fc4fcb29-690d-405f-9247-0c3739bb1467@github.com>

On Wed, 4 Sep 2024 19:03:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8003887: Use Assumptions.assumeTrue() and other and other cleanup

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20801#pullrequestreview-2281033563

From mcimadamore at openjdk.org  Wed Sep  4 20:35:47 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Sep 2024 20:35:47 GMT
Subject: RFR: 8339285: test fails with assert(depth < max_critical_stack_depth)
 failed: can't have more than 10 critical frames
Message-ID: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>

Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).

To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.

A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).

This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.

To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.

Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

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

Commit messages:
 - Use registerNatives on MappedMemoryUtils native methods
 - Merge branch 'master' into mapped_test_handshake
 - Add test

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

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

From liach at openjdk.org  Wed Sep  4 22:03:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 22:03:32 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v3]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <MENyKtpRieO98iSYemE5S83oOpvvVZoxM9NAoT6Pmr8=.5e395629-fa2a-4a96-8c7e-7aa3e3851316@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

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

 - Fix compile errors
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Compile errors; now tests are all green.
 - Move Constant Pool tags to PoolEntry
   
   Two unexpected usages in jlink raw processing, but rest is fine
 - opcode values moved to OpcodeValues
   
   less impactful than imagined, no longer need to qualify Opcode use when star importing ClassFile
 - Hide default class flags as well
 - Simplify SimpleVerificationTypeInfo's constant names
 - 8339260: Move rarely used constants out of ClassFile

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

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=02
  Stats: 2614 lines in 37 files changed: 865 ins; 905 del; 844 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

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

From swen at openjdk.org  Wed Sep  4 22:47:53 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 22:47:53 GMT
Subject: Integrated: 8338937: Optimize the string concatenation of ClassDesc
In-Reply-To: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
Message-ID: <6Gu8KFvmmrqlUfjVQwPMafl2v200TXpXHgQRPTvvWh8=.36f2c866-bec1-4c75-b1f2-2c35533d15f9@github.com>

On Sun, 25 Aug 2024 13:36:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The string concatenation of java.base module is implemented based on StringBuilder, which will result in extra object allocation and slow performance. We can solve this problem by using String.concat method and StringConcatHelper to provide concat method.
> 
> for example, 
> 
> * use "+"
> 
> class ClassDesc {
>     default String displayName() {
>         c.displayName() + "[]".repeat(depth)
>     }
> }
> 
> 
> bytecode:
> 
> 106: new           #40                 // class java/lang/StringBuilder
> 109: dup
> 110: invokespecial #42                 // Method java/lang/StringBuilder."<init>":()V
> 113: aload_2
> 114: invokeinterface #195,  1          // InterfaceMethod displayName:()Ljava/lang/String;
> 119: invokevirtual #50                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
> 122: ldc           #198                // String []
> 124: iload_1
> 125: invokevirtual #200                // Method java/lang/String.repeat:(I)Ljava/lang/String;
> 128: invokevirtual #50                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
> 131: invokevirtual #53                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
> 134: areturn
> 
> 
> * use String#concat
> 
> c.displayName().concat("[]".repeat(depth))
> 
> 
> bytecode:
> 
> 112: ldc           #198                // String []
> 114: iload_1
> 115: invokevirtual #200                // Method java/lang/String.repeat:(I)Ljava/lang/String;
> 118: invokevirtual #86                 // Method java/lang/String.concat:(Ljava/lang/String;)Ljava/lang/String;

This pull request has now been integrated.

Changeset: 55312e15
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55312e1549c36be46b0f3b3b40763a33311c3e25
Stats:     57 lines in 7 files changed: 39 ins; 4 del; 14 mod

8338937: Optimize the string concatenation of ClassDesc

Reviewed-by: liach

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

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

From swen at openjdk.org  Wed Sep  4 23:17:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 23:17:00 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <YOeL19YWRocDvDhcVQ581gwBNsls5E6YLPCzdjNHPFY=.dfe0420d-5658-4c42-8ffe-963508b2cb4a@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
 <YOeL19YWRocDvDhcVQ581gwBNsls5E6YLPCzdjNHPFY=.dfe0420d-5658-4c42-8ffe-963508b2cb4a@github.com>
Message-ID: <hdGXCZg_okB4X_p45_sRpNG9lPABcldKjCHeJMW94P0=.e7e49146-7f94-45b3-9228-c79a292d84b7@github.com>

On Wed, 4 Sep 2024 18:09:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   from @cl4es 's suggestion
>
> test/jdk/java/lang/String/CountNonZeroAscii.java line 35:
> 
>> 33:  * @modules java.base/jdk.internal.access
>> 34:  * @summary test latin1 String countNonZeroAscii
>> 35:  * @run testng/othervm -XX:+CompactStrings CountNonZeroAscii
> 
> You are using the `testng` driver for a `main` test. I can probably fix it quickly.

Is it recommended to change it to this?

/*
 * @test
 * @modules java.base/jdk.internal.access
 * @summary test latin1 String countNonZeroAscii
 * @run main/othervm -XX:+CompactStrings CountNonZeroAscii
 * @run main/othervm -XX:-CompactStrings CountNonZeroAscii
 */
``

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1744609167

From swen at openjdk.org  Wed Sep  4 23:25:30 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Sep 2024 23:25:30 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v6]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <yflu1ahNfoNOPGRD-x6l1u8Z1GW6nx8MKB_xzOXU5pU=.d3bc658a-0662-4d80-b228-bba3c4f588a9@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

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

 - Merge remote-tracking branch 'upstream/master' into optim_util_slotSize_20240828
 - Merge remote-tracking branch 'upstream/master' into optim_util_slotSize_20240828
 - suggestion from @cl4es
 - add benchmark
 - suggestion from @liach & @cl4es
 - Suggestions from @cl4es
 - optimize slotSize & isDoubleSlot

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/972ba60d..550216ab

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

  Stats: 12812 lines in 445 files changed: 7859 ins; 2260 del; 2693 mod
  Patch: https://git.openjdk.org/jdk/pull/20747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20747/head:pull/20747

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

From jiangli at openjdk.org  Wed Sep  4 23:39:54 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 4 Sep 2024 23:39:54 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

make/StaticLibs.gmk line 1:

> 1: #

Perhaps also consider adopting StaticLink.gmk file name from the https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, as we are mostly doing the static linking here. Creating the static libs is handled elsewhere.

make/StaticLibs.gmk line 71:

> 69:   # libsspi_bridge has name conflicts with sunmscapi
> 70:   BROKEN_STATIC_LIBS += sspi_bridge
> 71:   # These libs define DllMain which conflict with Hotspot

I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch.

make/StaticLibs.gmk line 74:

> 72:   BROKEN_STATIC_LIBS += awt dt_shmem dt_socket javaaccessbridge
> 73:   # These libs are dependent on any of the above disabled libs
> 74:   BROKEN_STATIC_LIBS += fontmanager jawt lcms net nio

Which specific dependent cause these libs being excluded? In https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, these JDK libs (except `libjawt.a`) are statically linked into `javastatic`.

make/StaticLibs.gmk line 118:

> 116:     OPTIMIZATION := HIGH, \
> 117:     STATIC_LAUNCHER := true, \
> 118:     LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \

I could be missing something, but I don't see where is $JAVASTATIC_LINK_LDFLAGS defined.

On a related notes, I think we need to include $JVM_LDFLAGS when linking the static "java". See https://bugs.openjdk.org/browse/JDK-8339522?focusedId=14702923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14702923.

make/modules/java.desktop/lib/AwtLibraries.gmk line 176:

> 174: 
> 175:   ifneq ($(ENABLE_HEADLESS_ONLY), true)
> 176:     # We cannot link with both awt_headless and awt_xawt at the same time

Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java.

src/java.base/unix/native/libjli/java_md.c line 300:

> 298:                            char jvmcfg[],  jint so_jvmcfg) {
> 299:     /* Compute/set the name of the executable. This is needed for macOS. */
> 300:     SetExecname(*pargv);

Why is `SetExecname()` needed for the static case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744614583
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744604685
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744603414
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744611776
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744616878
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744620611

From liach at openjdk.org  Wed Sep  4 23:47:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Sep 2024 23:47:52 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]
In-Reply-To: <hdGXCZg_okB4X_p45_sRpNG9lPABcldKjCHeJMW94P0=.e7e49146-7f94-45b3-9228-c79a292d84b7@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <Czanzk1M4JDKKY6J-DKyu98lFuT6JSmxjmpCC69kTkE=.efd24d8b-282e-478b-8e4e-80cf01c73733@github.com>
 <YOeL19YWRocDvDhcVQ581gwBNsls5E6YLPCzdjNHPFY=.dfe0420d-5658-4c42-8ffe-963508b2cb4a@github.com>
 <hdGXCZg_okB4X_p45_sRpNG9lPABcldKjCHeJMW94P0=.e7e49146-7f94-45b3-9228-c79a292d84b7@github.com>
Message-ID: <s54oCS_AQIUHGk-05rkBIvYm9Y-lvxJiojnTU1CsG6w=.48d63eec-205b-4038-9621-8971325d9746@github.com>

On Wed, 4 Sep 2024 23:14:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> test/jdk/java/lang/String/CountNonZeroAscii.java line 35:
>> 
>>> 33:  * @modules java.base/jdk.internal.access
>>> 34:  * @summary test latin1 String countNonZeroAscii
>>> 35:  * @run testng/othervm -XX:+CompactStrings CountNonZeroAscii
>> 
>> You are using the `testng` driver for a `main` test. I can probably fix it quickly.
>
> Is it recommended to change it to this?
> 
> /*
>  * @test
>  * @modules java.base/jdk.internal.access
>  * @summary test latin1 String countNonZeroAscii
>  * @run main/othervm -XX:+CompactStrings CountNonZeroAscii
>  * @run main/othervm -XX:-CompactStrings CountNonZeroAscii
>  */
> ``

Yes, that fixes this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1744626250

From jiangli at openjdk.org  Thu Sep  5 00:05:50 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 00:05:50 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <yIflmF7xMl0tVULX6Hy87pMUllWz6FkuJx4fji1t004=.aec2f5c1-2106-4dbe-83a6-2c0a8cdda35a@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

src/hotspot/share/classfile/classLoader.cpp line 953:

> 951:   assert(CanonicalizeEntry == nullptr, "should not load java library twice");
> 952:   if (is_vm_statically_linked()) {
> 953:     CanonicalizeEntry = CAST_TO_FN_PTR(canonicalize_fn_t, os::lookup_function("JDK_Canonicalize"));

Can you add an assert to make sure `CanonicalizeEntry` is not NULL?

src/hotspot/share/classfile/classLoader.cpp line 969:

> 967: 
> 968:   if (is_vm_statically_linked()) {
> 969:       JImageOpen = CAST_TO_FN_PTR(JImageOpen_t, os::lookup_function("JIMAGE_Open"));

It might be good to assert these are not NULL as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744635408
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744635916

From redestad at openjdk.org  Thu Sep  5 00:09:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Sep 2024 00:09:55 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v6]
In-Reply-To: <yflu1ahNfoNOPGRD-x6l1u8Z1GW6nx8MKB_xzOXU5pU=.d3bc658a-0662-4d80-b228-bba3c4f588a9@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <yflu1ahNfoNOPGRD-x6l1u8Z1GW6nx8MKB_xzOXU5pU=.d3bc658a-0662-4d80-b228-bba3c4f588a9@github.com>
Message-ID: <MBvjUriFU_QH65VJtnesLH6gphDBAnyld-XRWJI3zMg=.94855a17-e872-4d7f-8af0-a10c4fcc09e8@github.com>

On Wed, 4 Sep 2024 23:25:30 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> 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 seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_util_slotSize_20240828
>  - Merge remote-tracking branch 'upstream/master' into optim_util_slotSize_20240828
>  - suggestion from @cl4es
>  - add benchmark
>  - suggestion from @liach & @cl4es
>  - Suggestions from @cl4es
>  - optimize slotSize & isDoubleSlot

I don't think this microbenchmark is worth it. 

It's fine as an experiment and to motivate and include numbers for this PR, but micros we commit into the OpenJDK should limit themselves to public APIs (unless it's critical to have an isolated test for some reason).

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20747#pullrequestreview-2281613017

From jiangli at openjdk.org  Thu Sep  5 00:17:51 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 00:17:51 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <WfweadNY7uFR6FfVedxH7wIXrPZvwgtIo9evDUkfwZc=.39943e16-32d8-43a1-b55a-f1f7eca540c6@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

src/java.base/unix/native/libjli/java_md.c line 509:

> 507: 
> 508:     if (GetApplicationHome(path, pathsize)) {
> 509:         if (JLI_IsStaticallyLinked()) {

`GetJREPath()` does not need to be called for the static case. Any reason why this path is executed for static mode?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744642315

From jiangli at openjdk.org  Thu Sep  5 00:27:50 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 00:27:50 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <b4JPTQvVYy0YD37EA4fkGyoqdNDhmJoI3b5Nmap_Z5A=.8733d6e4-12a7-47da-9c90-87e1836d7a27@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <b4JPTQvVYy0YD37EA4fkGyoqdNDhmJoI3b5Nmap_Z5A=.8733d6e4-12a7-47da-9c90-87e1836d7a27@github.com>
Message-ID: <4ZyGLLJL7fVUDI0QXFBOZ1dK97dOjWKDuDCBhsPqEHs=.ac87ad4f-0839-4d5d-a59e-b273f37a6711@github.com>

On Tue, 3 Sep 2024 12:51:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @jianglizhou Can you please check if there are any other contributors that should be acknowledged?

Thanks for asking! I checked all the related changes in https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. Following are the related commits from the branch corresponding to the extracted changes included in this PR. There are no other author for those changes. However, all changes have go though prior reviews by my teammates. I didn't ask it for the earlier integration PR, is there way to mention the reviewer contributions?

- https://github.com/openjdk/leyden/commit/bceb753f79b4bc767fdfb71d5f68a84430644df6
- https://github.com/openjdk/leyden/commit/a998a9d6ca44a93d4e9859a17de2dca60963de76
- https://github.com/openjdk/leyden/commit/53aa8f0cf418ab5f435a4b9996c7754fb8505d4b
- https://github.com/openjdk/leyden/commit/63f84f5c0a98077c8f49a19f026f103b9e29d6e0
- https://github.com/openjdk/leyden/commit/afe9ca06dd86e8983768de80ba1a08f3c68589b4
- https://github.com/openjdk/leyden/commit/7d75a7f4d6aa020b7580fbbf660b2b3e3a41b27

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2330368791

From swen at openjdk.org  Thu Sep  5 00:48:26 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 00:48:26 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v21]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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

  suggestion from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/c257cf36..962d1447

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=19-20

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

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

From liach at openjdk.org  Thu Sep  5 00:57:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 00:57:04 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v21]
In-Reply-To: <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>
Message-ID: <Ik-HVV_GXZdA-GIZo17Gtzib7LzHYZqbcTFzm9ig_ZU=.9b5020b9-558a-48a4-9008-69e2062d3d5f@github.com>

On Thu, 5 Sep 2024 00:48:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2281655558

From liach at openjdk.org  Thu Sep  5 04:50:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 04:50:24 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
Message-ID: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>

Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.

RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.

Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.

Pinging @wenshao and @cl4es for review.

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

Commit messages:
 - Simplify state transition logic, fix dump logical error and comment error
 - Use inlined representation for class initializer, loop initialization too costly
 - Bad assertion
 - Encapsulate RawBytecodeHelper, controlled unchecked access
 - remove benchmark
 - Inline ByteBuffer into RawBytecodeHelper, and try to make it eligible for escape analysis
 - simplify ByteBuffer improve startup performance
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/20863/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339576
  Stats: 471 lines in 9 files changed: 196 ins; 101 del; 174 mod
  Patch: https://git.openjdk.org/jdk/pull/20863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20863/head:pull/20863

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

From duke at openjdk.org  Thu Sep  5 04:50:24 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 5 Sep 2024 04:50:24 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
Message-ID: <wqBxR6-m-3tZuudUvXdFdjfKr1bUwcC07p05lkY6p6c=.98d7f6b4-d779-4aec-b171-65bb55df890f@github.com>

On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
> 
> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
> 
> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
> 
> Pinging @wenshao and @cl4es for review.

src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 56:

> 54: 
> 55:     /**
> 56:      * The length of opcodes, 0 for

What?does ?0?for? mean?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1744723092

From liach at openjdk.org  Thu Sep  5 04:50:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 04:50:24 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <wqBxR6-m-3tZuudUvXdFdjfKr1bUwcC07p05lkY6p6c=.98d7f6b4-d779-4aec-b171-65bb55df890f@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <wqBxR6-m-3tZuudUvXdFdjfKr1bUwcC07p05lkY6p6c=.98d7f6b4-d779-4aec-b171-65bb55df890f@github.com>
Message-ID: <qj5adUm6CECQbnHUWpfzWGsJ1yP_g_WF5PilD1oTYdI=.37a6fd28-234f-4150-9713-b3851af5ed02@github.com>

On Thu, 5 Sep 2024 02:31:48 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
>> 
>> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
>> 
>> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
>> 
>> Pinging @wenshao and @cl4es for review.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 56:
> 
>> 54: 
>> 55:     /**
>> 56:      * The length of opcodes, 0 for
> 
> What?does ?0?for? mean?

nothing :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1744732436

From swen at openjdk.org  Thu Sep  5 05:03:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 05:03:22 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v7]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <nzPSgfItpM6AWc9N8hoRonH9yGlX_iWiH6jSe_-DZ4c=.530791f8-54df-4806-877e-b50c99f03951@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

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

  optimize parameterSlots

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/550216ab..661639ab

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

  Stats: 13 lines in 2 files changed: 5 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20747/head:pull/20747

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

From swen at openjdk.org  Thu Sep  5 05:07:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 05:07:12 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v8]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

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

  remove benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/661639ab..e76b25b8

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

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

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

From miiiinju00 at gmail.com  Thu Sep  5 05:10:02 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Thu, 5 Sep 2024 14:10:02 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
Message-ID: <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>

Hi Daniel

I hope you're doing well. I wanted to follow up on a previous message I sent. Since this is my first time contributing to OpenJDK, I realized I might not have communicated the issue clearly, and I wanted to provide more context about the situation I encountered.

In the put() method of LinkedBlockingQueue, when the queue reaches its capacity, threads block on notFull.await(). For example, if threads T1, T2, T3, and T4 call put() in sequence when the queue is full, they all wait in the notFull.await() state in sequence as expected.

Normally, when space becomes available in the queue, I would expect the thread that called put() first (T1) to be signaled, allowing it to proceed in FIFO order. However, the issue arises when a new thread, T5, tries to put() at the same time T1 is signaled to proceed.

In this scenario, both T1 (which was waiting) and T5 (which just arrived) compete for the ReentrantLock. This competition can lead to T5 acquiring the lock first, allowing it to perform the put() operation before T1, despite T1 having waited the longest. As a result, T1 experiences "starvation," and the order becomes T2, T3, T4, and finally T1, which breaks the expected FIFO order.

In the test code I provided, if you remove the capacity limit of the queue, the mentioned issue does not occur, and the test passes successfully. You can confirm this by using the new LinkedBlockingQueue<>() constructor without any capacity-related options.

In a previous discussion, there was a suggestion to synchronize the sequenceNumber and queue.put() using an external lock. However, my intention was to simulate a scenario where T1, T2, T3, and T4 all block in the await() state after sequentially attempting put(). I wanted to observe how they behave when a new thread (T5) arrives and competes for the lock.

If I use an external lock, T1 will block in the await() state, but T2, T3, and T4 will be waiting for the external lock rather than entering the await() state in put(). This would prevent me from simulating the specific behavior I?m trying to test.

I?d appreciate your thoughts on whether this behavior (where a newly arriving thread can overtake a waiting thread) is expected or if it?s worth further investigation. As this is my first attempt to contribute to OpenJDK, I?m eager to learn from the process and would love to help resolve the issue if necessary.

Also, since English is not my first language, I hope my previous emails didn?t come across as rude or unclear. If they did, I sincerely apologize, as it was never my intention to be disrespectful. I?m still learning how to communicate effectively in this space, and I appreciate your understanding and patience.

Thank you for your time and guidance.

Best regards,

Kim Minju


> 2024. 9. 4. ?? 9:35, Daniel Fuchs <daniel.fuchs at oracle.com> ??:
> 
> Hi Kim,
> 
> On 04/09/2024 12:50, ??? wrote:
>> In the original approach, I intended for each thread to call |put|, confirm that it has entered the waiting state, and then allow the next thread to put the next sequence value and also enter the waiting state. This approach was designed to simulate a situation where the queue is already full and each thread has to wait in line for space to become available.
> 
> The problem with that is that you would still need to ensure that each
> thread calls `put` in order, and for that, you would still need
> external synchronization.
> 
> I am not an expert in java.util.concurrent, but it feels like the
> fix you had in mind would not buy you much.
> 
> best regards,
> 
> -- daniel
> 

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

From jwaters at openjdk.org  Thu Sep  5 05:11:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 5 Sep 2024 05:11:55 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
Message-ID: <bfBaJj8ARo7c7iCF7U4ymPRfAbtKotBqj5WU_4z9490=.60be0f5a-a237-4496-905b-ef51128b3189@github.com>

On Wed, 4 Sep 2024 23:06:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> make/StaticLibs.gmk line 71:
> 
>> 69:   # libsspi_bridge has name conflicts with sunmscapi
>> 70:   BROKEN_STATIC_LIBS += sspi_bridge
>> 71:   # These libs define DllMain which conflict with Hotspot
> 
> I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch.

DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMain 
 when compiling them as static libraries

> src/hotspot/share/classfile/classLoader.cpp line 953:
> 
>> 951:   assert(CanonicalizeEntry == nullptr, "should not load java library twice");
>> 952:   if (is_vm_statically_linked()) {
>> 953:     CanonicalizeEntry = CAST_TO_FN_PTR(canonicalize_fn_t, os::lookup_function("JDK_Canonicalize"));
> 
> Can you add an assert to make sure `CanonicalizeEntry` is not NULL?

Also please remember to use nullptr and not NULL! @kimbarrett would appreciate it :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744808169
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744810286

From Marko.Baksic at infobip.com  Thu Sep  5 05:23:48 2024
From: Marko.Baksic at infobip.com (=?utf-8?B?TWFya28gQmFrxaFpxIc=?=)
Date: Thu, 5 Sep 2024 05:23:48 +0000
Subject: Possible bug in jdk.naming.dns. I need guidance on how get
 someone smarter to look at it.
In-Reply-To: <IA0PR10MB7304155FA7DBB0DB4301DDF7EC9C2@IA0PR10MB7304.namprd10.prod.outlook.com>
References: <DU0PR01MB99669CF7EFE32A88F963790D859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
 <e059b25a-4981-43e5-bfe5-c1bb047d1f73@oracle.com>
 <DU0PR01MB9966DBCCA54B08D998D650DA859C2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>
 <bb5542ce-26db-4d08-bbba-1106a3769697@oracle.com>
 <IA0PR10MB7304155FA7DBB0DB4301DDF7EC9C2@IA0PR10MB7304.namprd10.prod.outlook.com>
Message-ID: <DU0PR01MB99662B39B0CC2821553F50DC859D2@DU0PR01MB9966.eurprd01.prod.exchangelabs.com>

Awesome, thank you guys.

-- Marko



[cid:Infobip_logo_vertical_signature_e28e13d2-255b-4571-a70c-8292f2d75c0b.png]

Marko Bak?i?

Software Engineer


E Marko.Baksic at infobip.com

M


A Utinjska 29A, 10000 Zagreb, Croatia

www.infobip.com<http://www.infobip.com>







________________________________
From: Aleksei Efimov <aleksej.efimov at oracle.com>
Sent: Wednesday, September 4, 2024 17:29
To: Daniel FUCHS <daniel.fuchs at oracle.com>; Marko Bak?i? <Marko.Baksic at infobip.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: [EXTERNAL] Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Thank you, Marko - it's an excellent catch! Indeed, we have a bug in a code that updates the left timeout. And yes, we should use nanoTime for measuring elapsed time. I will work on a fix for both issues and will try to create a test for the left timeout update scenario.

- Aleksei
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: 04 September 2024 3:59 PM
To: Marko Bak?i? <Marko.Baksic at infobip.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

On 04/09/2024 15:02, Marko Bak?i? wrote:
> Thank you Daniel.
>
> The part that was suspicious to me is
>
> ```
> int timeoutLeft = pktTimeout;
> do {
> ??????...
> ??????timeoutLeft = pktTimeout - ((int) (end - start));
> } while (timeoutLeft > MIN_TIMEOUT);
> ```
>
> Here, timeoutLeft is not iteratively decreased, but is always derived
> from `pktTimeout`.
> I can see a case where `timeoutLeft` never drops below `MIN_TIMEOUT`
> (this is the part where I'm not sure if I'm missing some deeper knowledge).

Indeed - good observation!

-- daniel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/230a9d3f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2551 bytes
Desc: Infobip_logo_vertical_signature_e28e13d2-255b-4571-a70c-8292f2d75c0b.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/230a9d3f/attachment-0001.png>

From swen at openjdk.org  Thu Sep  5 05:54:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 05:54:50 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v8]
In-Reply-To: <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
Message-ID: <1LuyL4qrAp24tkc7-BtZUm9QWCw9wMU_-D1UORKmusM=.367d6342-05b1-4e0d-98a6-6aad46670b7f@github.com>

On Thu, 5 Sep 2024 05:07:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove benchmark

![image](https://github.com/user-attachments/assets/82b806f5-6b16-4faf-86aa-5101e5fedc82)
When I was doing performance analysis, I found that slotSize appeared in the flame graph. The above picture is based on the performance data of PR #20863. You can see the slotSize in the red box. The current optimization is to eliminate this part. The overall test cannot reflect this optimization, which is why I created UtilBench. I have removed it.

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

PR Comment: https://git.openjdk.org/jdk/pull/20747#issuecomment-2330657780

From alanb at openjdk.org  Thu Sep  5 06:24:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 06:24:08 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v2]
In-Reply-To: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
Message-ID: <gGNfGRJt44B5fXiSnci08WmfxJjZScsjaF3d7RL8hxc=.fb225970-4e0b-4f63-825f-39eb4edac335@github.com>

> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html) and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
> 
> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
> 
> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
> 
> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).

Alan Bateman 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:

 - Sync up from loom repo
 - Merge
 - Sync up from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20816/files
  - new: https://git.openjdk.org/jdk/pull/20816/files/fe1d7de6..1ce1a6ac

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

  Stats: 4914 lines in 216 files changed: 2632 ins; 1088 del; 1194 mod
  Patch: https://git.openjdk.org/jdk/pull/20816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20816/head:pull/20816

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

From swen at openjdk.org  Thu Sep  5 06:28:49 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 06:28:49 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
Message-ID: <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>

On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
> 
> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
> 
> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
> 
> Pinging @wenshao and @cl4es for review.

src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 235:

> 233:      * we have a valid opcode.
> 234:      */
> 235:     public boolean next() {

In C1, this cannot be inlined. See if you need to add ForceInline

src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 242:

> 240:         bci = nextBci;
> 241:         int code = getU1Unchecked(bci);
> 242:         int len = LENGTHS[code];

Adding `& 0xFF` here can eliminate array out-of-bounds detection

int len = LENGTHS[code & 0xFF];

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1744871326
PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1744872686

From redestad at openjdk.org  Thu Sep  5 07:09:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Sep 2024 07:09:53 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v21]
In-Reply-To: <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>
Message-ID: <CK2bfYw1hJd7_AWT1pADRw4csjf9m93kJCHBsGQ-1Cg=.43a158cf-516f-4b3f-9f6b-eb6111013da1@github.com>

On Thu, 5 Sep 2024 00:48:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2282032617

From pminborg at openjdk.org  Thu Sep  5 07:18:45 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 07:18:45 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v2]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <r4-1oJ8v9WFi2X3khhAqWglFpX54bFNUGmU0VAbSDKM=.1fd31c7a-7f63-44d5-80d3-6654feb78c85@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Update src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/487629d9..44fb43e8

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

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

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

From jbhateja at openjdk.org  Thu Sep  5 07:45:17 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Sep 2024 07:45:17 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v6]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <ul2peI-SF6u9H78IHdWHWBw5FYJdXFAsx1CRMaNK6uU=.4008581d-b05f-4afb-8913-7f27043931e9@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Review suggestions incorportated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/767aeef3..bec0f449

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

  Stats: 1979 lines in 59 files changed: 670 ins; 809 del; 500 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From jbhateja at openjdk.org  Thu Sep  5 07:45:17 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Sep 2024 07:45:17 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <TQRt9w38cIX-gRkjVANWp0aZU5mNwcU95R09ISuTo7c=.4de988d2-bd8b-43fe-9b0c-15821f82d5e0@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
 <TQRt9w38cIX-gRkjVANWp0aZU5mNwcU95R09ISuTo7c=.4de988d2-bd8b-43fe-9b0c-15821f82d5e0@github.com>
Message-ID: <7huBzF7ygKcr1ADKYTizGsyEBNb6dWYaU3g9_StUGB4=.89495de4-e6b5-47d6-9756-41471d366211@github.com>

On Tue, 3 Sep 2024 13:09:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> You did in fact add `java/lang` methods. I think you need to add tests for all of those. As well. That's going to be even more code to review.

Hi @eme64 , As Paul suggested in offline mail chain, lets restrict the changes with this patch to only VectorAPI. Going forward we may need to add special Unsigned value classes wrapping around equivalent sized integers. For the time being moving all the helper APIs int VectorMathUtils.java, these automatically gets exercised by the fallback implementation and we already have tests for next APIs.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 914:
> 
>> 912:       case T_SHORT: vpminuw(dst, src1, src2, vlen_enc); break;
>> 913:       case T_INT:   vpminud(dst, src1, src2, vlen_enc); break;
>> 914:       case T_LONG:  evpminuq(dst, k0, src1, src2, false, vlen_enc); break;
> 
> Can you explain to me what the `k0` is and where it comes from?

k0 is an implicit mask register which signifies all true mask. Its not allocatable.  Long min / max instructions are only available on AVX512 targets.

> src/hotspot/share/opto/addnode.hpp line 194:
> 
>> 192: class SaturatingAddINode : public Node {
>> 193: public:
>> 194:   SaturatingAddINode(Node* in1, Node* in2) : Node(in1,in2) {}
> 
> Suggestion:
> 
>   SaturatingAddINode(Node* in1, Node* in2) : Node(in1, in2) {}
> 
> In other places below as well.

Not applicable now.

> src/hotspot/share/opto/addnode.hpp line 198:
> 
>> 196:   virtual const Type* bottom_type() const { return TypeInt::INT; }
>> 197:   virtual uint ideal_reg() const { return Op_RegI; }
>> 198: };
> 
> Are these not supposed to inherit from the `AddNode`, and then override the corresponding methods? Or are you making them separate for a good reason?

As per offline discussion with Paul, we are planning to restrict this patch to only Vector API, please refer to my earlier comments, https://github.com/openjdk/jdk/pull/20507#discussion_r1718044262
To reduce the noise I am keeping only required Vector IR nodes and planning to support scalar saturated operations in subsequent patch.

> src/hotspot/share/opto/addnode.hpp line 462:
> 
>> 460: //------------------------------UMaxINode---------------------------------------
>> 461: // Maximum of 2 unsigned integers.
>> 462: class UMaxLNode : public Node {
> 
> Here you comment it with `UMaxINode`, but below it is the `UMaxLNode`. The `-------xyz------` comments are really useless. But the semantics description is useful (though you again say integer instead of long here...).

Not applicable now.

> src/hotspot/share/opto/vectornode.hpp line 634:
> 
>> 632:   virtual int Opcode() const;
>> 633: };
>> 634: 
> 
> This could also be a separate PR. Or are they somehow inseparable from the "saturation" changes?

Not applicable now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2330830123
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744971176
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744970961
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744971087
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744971023
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744970833

From jbhateja at openjdk.org  Thu Sep  5 07:45:18 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Sep 2024 07:45:18 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <A_tYeYCbRsSRTuVsfTvw-dVKaXVkuZ6NvzUugC7rmGI=.e0d7b639-e306-4949-9116-6136c2b0ad4b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
 <A_tYeYCbRsSRTuVsfTvw-dVKaXVkuZ6NvzUugC7rmGI=.e0d7b639-e306-4949-9116-6136c2b0ad4b@github.com>
Message-ID: <73QhgX2mQ9TBRQSq57MyimsFExG0tOKv6_id6EuCV_c=.03442b40-a24d-4623-8f1e-6050087c0e0d@github.com>

On Tue, 3 Sep 2024 22:18:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolved
>
> src/hotspot/cpu/x86/x86.ad line 10684:
> 
>> 10682:   match(Set dst (SaturatingSubVI src1 src2));
>> 10683:   match(Set dst (SaturatingSubVL src1 src2));
>> 10684:   effect(TEMP xtmp1, TEMP xtmp2);
> 
> Here we need TEMP dst in effect, the saturating_unsigned_sub_dq_avx defines and uses dst across xtmp1.

Thanks, yes live range of MachNode corresponding to TEMP ends at its consumer instruction, they never make their way into liveout set of its block or survive beyond consumer, but back to back updates to DST and TMP may corrupt DST if both are assigned same registers by allocator.

> src/java.base/share/classes/java/lang/Long.java line 1987:
> 
>> 1985:     public static long addSaturating(long a, long b) {
>> 1986:         long res = a + b;
>> 1987:         // HD 2-12 Overflow iff both arguments have the opposite sign of the result
> 
> HD -> Hacker's Delight

Thanks for elaborating, I replicated this logic from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L930
Wanted to comply with rest of the codes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744970392
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1744970574

From redestad at openjdk.org  Thu Sep  5 08:27:46 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Sep 2024 08:27:46 GMT
Subject: RFR: 8339592: Simplify and remove unused code in
 ObjectMethods.<clinit>
Message-ID: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>

A few trivial(?) cleanups to `java.lang.runtime.ObjectMethods`:
- Avoid `MethodType.fromDescriptorString` which needs a classloader
- Use `MethodHandles.zero`
- Remove unused static `MethodHandles` and `MethodTypes`

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

Commit messages:
 - 8339592: Simplify and remove unused code in ObjectMethods.<clinit>

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

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

From pminborg at openjdk.org  Thu Sep  5 08:34:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 08:34:11 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v3]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <0G2-5wDlXRe4fXKRqy9V4CCmhUVa_4J4Xe8aglX0ukM=.d4e85f86-6886-4b0a-a730-fa6e836c876f@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

 - Merge branch 'master' into mismatch-performance2
 - Move fill to SegmentBulkOperations
 - Add system property and improve benchmark
 - Update src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Remove temp methods
 - Clean up
 - Update comment
 - Merge branch 'master' into mismatch-performance2
 - Create a separate class for segment bulk operations
 - Add Java implementation of MS::mismatch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/44fb43e8..14184901

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

  Stats: 1878 lines in 115 files changed: 926 ins; 534 del; 418 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From jbhateja at openjdk.org  Thu Sep  5 08:34:36 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Sep 2024 08:34:36 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v7]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Some cleanups.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/bec0f449..7164783e

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

  Stats: 17 lines in 7 files changed: 2 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From nbenalla at openjdk.org  Thu Sep  5 08:49:14 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Sep 2024 08:49:14 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

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

  convert TestNullHostile to use JUnit Jupiter API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20556/files
  - new: https://git.openjdk.org/jdk/pull/20556/files/cf75c679..2e72dee1

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

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

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

From ihse at openjdk.org  Thu Sep  5 09:54:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 5 Sep 2024 09:54:52 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <bfBaJj8ARo7c7iCF7U4ymPRfAbtKotBqj5WU_4z9490=.60be0f5a-a237-4496-905b-ef51128b3189@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <bfBaJj8ARo7c7iCF7U4ymPRfAbtKotBqj5WU_4z9490=.60be0f5a-a237-4496-905b-ef51128b3189@github.com>
Message-ID: <KHRKhEhQIgvknE2mHJ059rYoYZVom7_E7k4mN2K55GM=.8d36647a-27d0-43e2-9a75-f20d9ee43477@github.com>

On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/StaticLibs.gmk line 71:
>> 
>>> 69:   # libsspi_bridge has name conflicts with sunmscapi
>>> 70:   BROKEN_STATIC_LIBS += sspi_bridge
>>> 71:   # These libs define DllMain which conflict with Hotspot
>> 
>> I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch.
>
> DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMai
 n when compiling them as static libraries

As Julian says, this is for Windows, and you have not even tried to compile that in your prototype.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745162496

From ihse at openjdk.org  Thu Sep  5 09:54:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 5 Sep 2024 09:54:53 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
Message-ID: <7tmo9e9RcUi06DYLjvQEaEu_XCY4bUa4OcWByw7vCdc=.11672bb7-71ca-46f4-8ed1-48512ab59e15@github.com>

On Wed, 4 Sep 2024 23:03:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> make/StaticLibs.gmk line 74:
> 
>> 72:   BROKEN_STATIC_LIBS += awt dt_shmem dt_socket javaaccessbridge
>> 73:   # These libs are dependent on any of the above disabled libs
>> 74:   BROKEN_STATIC_LIBS += fontmanager jawt lcms net nio
> 
> Which specific dependent cause these libs being excluded? In https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, these JDK libs (except `libjawt.a`) are statically linked into `javastatic`.

Well, but your proof-of-concept only supports clang on linux, where you have enabled symbol hiding. 

Our conclusion in the zoom talks was that we should strive for getting a static launcher build pushed into mainline before we have full and proper support for symbol hiding on all platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745161079

From alanb at openjdk.org  Thu Sep  5 09:58:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 09:58:50 GMT
Subject: RFR: 8339285: test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames
In-Reply-To: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
Message-ID: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com>

On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
> 
> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
> 
> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
> 
> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
> 
> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
> 
> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

src/java.base/aix/native/libnio/MappedMemoryUtils.c line 229:

> 227:     {"unload0",   "(JJ)V",              (void *)&MMU_unload0},
> 228:     {"force0",    "(" FD "JJ)V",        (void *)&MMU_force0},
> 229: };

I did a pass over this and I think it looks okay.

Do the MMU_* functions still need to be jni-exported? In any case, probably better to rename them to MemoryMemoryUtils_* to avoid anything looking at symbols and thinking they are something to do with the memory management unit :-)

It looks most of the signatures for this functions are misaligned with edits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745168389

From ihse at openjdk.org  Thu Sep  5 10:02:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 5 Sep 2024 10:02:59 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
Message-ID: <Yc36M18CA-LzcyvnVwL7D_8CE-nPC8WtO7gMnPzQ9-U=.353a312a-64f4-41d9-ae51-dcd93a2c819c@github.com>

On Wed, 4 Sep 2024 23:28:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> make/modules/java.desktop/lib/AwtLibraries.gmk line 176:
> 
>> 174: 
>> 175:   ifneq ($(ENABLE_HEADLESS_ONLY), true)
>> 176:     # We cannot link with both awt_headless and awt_xawt at the same time
> 
> Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java.

That would require quite some work then..! The two libraries are meant as exclusive complements to each other -- they both implement the same "entry points", but in different ways -- one with X11 support, and one without. For other reasons (outside of static launcher reasons) I'd like to see some refactoring in how this is implemented, but that is completely outside this discussion.

For the static launcher scenario, I can't even see the point of trying to include both? What would you accomplish by that? 

The entire point of having two libraries is that you want to be able to have full workstation capabilities, but then be dependent on the X11 libraries, or have limited capabilities, but skip the X11 dependency.

> src/java.base/unix/native/libjli/java_md.c line 300:
> 
>> 298:                            char jvmcfg[],  jint so_jvmcfg) {
>> 299:     /* Compute/set the name of the executable. This is needed for macOS. */
>> 300:     SetExecname(*pargv);
> 
> Why is `SetExecname()` needed for the static case?

Because of how macOS re-exec the launcher to reserve the main thread for GUI operations. Please check the rather extensive documentation elsewhere in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745171016
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745172749

From ihse at openjdk.org  Thu Sep  5 10:02:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 5 Sep 2024 10:02:58 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <dOHTFTlXDWQc_3M5zfjPeevfGHXv1ZJi5I3FLzJBWXg=.038829b7-b07a-4ace-bc3d-35402e98eeb5@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

The `/contributor` is supposed to add attribution to whomever wrote the code. There is no way to document any prior reviewing for code; but they are of course welcome to review this PR, and then it will be documented.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2331113024

From ihse at openjdk.org  Thu Sep  5 10:05:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 5 Sep 2024 10:05:56 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
Message-ID: <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>

On Wed, 4 Sep 2024 23:24:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> make/StaticLibs.gmk line 1:
> 
>> 1: #
> 
> Perhaps also consider adopting StaticLink.gmk file name from the https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, as we are mostly doing the static linking here. Creating the static libs is handled elsewhere.

My intention is to move all relevant handling of static linking into this file.

> make/StaticLibs.gmk line 118:
> 
>> 116:     OPTIMIZATION := HIGH, \
>> 117:     STATIC_LAUNCHER := true, \
>> 118:     LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \
> 
> I could be missing something, but I don't see where is $JAVASTATIC_LINK_LDFLAGS defined.
> 
> On a related notes, I think we need to include $JVM_LDFLAGS when linking the static "java". See https://bugs.openjdk.org/browse/JDK-8339522?focusedId=14702923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14702923.

You are right, this is dead code. Thanks for spotting this. 

During my experimentation, I tried passing along LDFLAGS from the individual libraries as well, but it turned out not to be a good idea -- the way we have used them were to modify some special properties on a single dynamic library, which did not apply to the static library as a whole.

However, there is a risk that we in the future need to add LDFLAGS to a library that also needs to be carried over to the static launcher. If this happens, I guess we need to separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745180739
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745180044

From alanb at openjdk.org  Thu Sep  5 10:19:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 10:19:51 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

src/java.base/unix/native/libjli/java_md.c line 509:

> 507: 
> 508:     if (GetApplicationHome(path, pathsize)) {
> 509:         if (JLI_IsStaticallyLinked()) {

In passing, GetJREPath's function description includes "or registry settings" which is confusing to see now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745198354

From duke at openjdk.org  Thu Sep  5 11:15:55 2024
From: duke at openjdk.org (duke)
Date: Thu, 5 Sep 2024 11:15:55 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v21]
In-Reply-To: <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <WMrhlC8vlAR_-xiFd-Qnxk-bs-QjHLh1qRL9iDGsFPM=.ba5ce490-8720-43fb-b6a1-1c7ebe775f26@github.com>
Message-ID: <JCIpfe7lNflTiH0z0bMQbhvlp0c9ZttF7atfw8wGJNk=.bbadcc07-4868-4eff-8317-4f3ab99209ff@github.com>

On Thu, 5 Sep 2024 00:48:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

@wenshao 
Your change (at version 962d1447cf6864aca7f5be959f0b5bd2fa6fb74e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20772#issuecomment-2331253888

From mcimadamore at openjdk.org  Thu Sep  5 11:17:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:17:34 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
Message-ID: <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>

> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
> 
> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
> 
> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
> 
> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
> 
> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
> 
> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20854/files
  - new: https://git.openjdk.org/jdk/pull/20854/files/5a4cd150..f02b51c1

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

  Stats: 45 lines in 3 files changed: 0 ins; 12 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/20854.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20854/head:pull/20854

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

From mcimadamore at openjdk.org  Thu Sep  5 11:17:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:17:34 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com>
Message-ID: <DWCxj9weg2ms0pq94MeXV5-zYYlZ5Pw819StJWKF9sc=.9f13de85-6dc3-4489-bcf9-3946c419266c@github.com>

On Thu, 5 Sep 2024 09:55:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do the MMU_* functions still need to be jni-exported?

I've now dropped JNIEXPORT, but kept JNICALL, as that is used to set `__stdcall` (at least on Windows).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745274541

From mcimadamore at openjdk.org  Thu Sep  5 11:19:52 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:19:52 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v3]
In-Reply-To: <0G2-5wDlXRe4fXKRqy9V4CCmhUVa_4J4Xe8aglX0ukM=.d4e85f86-6886-4b0a-a730-fa6e836c876f@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <0G2-5wDlXRe4fXKRqy9V4CCmhUVa_4J4Xe8aglX0ukM=.d4e85f86-6886-4b0a-a730-fa6e836c876f@github.com>
Message-ID: <pCIdGVpfkLE6BPg-LBheLyG4dUOS0n-UiqT-pqQ_TpY=.8fd7fd34-bb56-4511-a4b7-b6003e12247a@github.com>

On Thu, 5 Sep 2024 08:34:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into mismatch-performance2
>  - Move fill to SegmentBulkOperations
>  - Add system property and improve benchmark
>  - Update src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Remove temp methods
>  - Clean up
>  - Update comment
>  - Merge branch 'master' into mismatch-performance2
>  - Create a separate class for segment bulk operations
>  - Add Java implementation of MS::mismatch

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 56:

> 54:     // Update the value for Aarch64 once 8338975 is fixed.
> 55:     private static final long NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 10 : 5);
> 56:     private static final long NATIVE_THRESHOLD_MISMATCH = powerOfPropertyOr("mismatch", 20);

This large threshold will cause a regression on Linux x64 for heap segments.

test/micro/org/openjdk/bench/java/lang/foreign/Mismatch.java line 87:

> 85:     }
> 86: 
> 87:     @Fork(value = 3, jvmArgsAppend = {"-Djava.lang.foreign.native.threshold.power.mismatch=31"})

Should we add similar variants to the fill benchmarks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745280069
PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745277753

From alanb at openjdk.org  Thu Sep  5 11:31:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 11:31:52 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
Message-ID: <CV0k685d0YmB5Jd-xaDED_2Qsv8Azp2x3AXONISsnFM=.ebb7be59-0915-411e-8f86-415c9d101fff@github.com>

On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
>> 
>> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
>> 
>> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
>> 
>> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
>> 
>> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
>> 
>> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

test/jdk/java/foreign/TestMappedHandshake.java line 90:

> 88: 
> 89:             accessExecutor.shutdown();
> 90:             assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS));

ExecutorService is an AutoCloseable to you should be able to use try-with-resources and get rid of the the shutdown+awaitTermination.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745294794

From mcimadamore at openjdk.org  Thu Sep  5 11:42:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:42:51 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <CV0k685d0YmB5Jd-xaDED_2Qsv8Azp2x3AXONISsnFM=.ebb7be59-0915-411e-8f86-415c9d101fff@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
 <CV0k685d0YmB5Jd-xaDED_2Qsv8Azp2x3AXONISsnFM=.ebb7be59-0915-411e-8f86-415c9d101fff@github.com>
Message-ID: <Q0F3cuLbknmoYbD-TjjtrGVYO9LYEfdLrMEzPSEsw-o=.36286a3b-680b-45e2-818d-750f9acab829@github.com>

On Thu, 5 Sep 2024 11:29:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/java/foreign/TestMappedHandshake.java line 90:
> 
>> 88: 
>> 89:             accessExecutor.shutdown();
>> 90:             assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS));
> 
> ExecutorService is an AutoCloseable to you should be able to use try-with-resources and get rid of the the shutdown+awaitTermination.

The test (like also its sibling `TestHandshake`) is deliberately using `shutdown`/`awaitTermination` to make sure the test finished in a reasonable amount of time (and generate correct assertion failures if it doesn't). This was mostly added to have better debugging at a time when `TestHandshake` was failing spuriously, so I'd prefer to leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745307197

From swen at openjdk.org  Thu Sep  5 11:48:59 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 11:48:59 GMT
Subject: Integrated: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <mXV7Y8c_IjfLxQYfBhI8oD9xdaN6M01wJCd7-7IrLAA=.dd033d96-8f1f-4870-8dc2-cab839b5b066@github.com>

On Thu, 29 Aug 2024 14:38:20 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

This pull request has now been integrated.

Changeset: cb9f5c57
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb9f5c5791d17afbf72f7debe8013b77e45b3b56
Stats:     315 lines in 7 files changed: 266 ins; 47 del; 2 mod

8339290: Optimize ClassFile Utf8EntryImpl#writeTo

Reviewed-by: redestad, liach

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

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

From pminborg at openjdk.org  Thu Sep  5 12:09:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 12:09:06 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v4]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <5NRkEOCATPalfgvkVaiwGVJk0AFjvepuh6WZFfHJFG8=.2bd5c19d-f07a-41f8-8b1a-d9f27a2ff245@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Add optimized checking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/14184901..c421c620

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

  Stats: 89 lines in 2 files changed: 83 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From pminborg at openjdk.org  Thu Sep  5 12:09:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 12:09:08 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v3]
In-Reply-To: <pCIdGVpfkLE6BPg-LBheLyG4dUOS0n-UiqT-pqQ_TpY=.8fd7fd34-bb56-4511-a4b7-b6003e12247a@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <0G2-5wDlXRe4fXKRqy9V4CCmhUVa_4J4Xe8aglX0ukM=.d4e85f86-6886-4b0a-a730-fa6e836c876f@github.com>
 <pCIdGVpfkLE6BPg-LBheLyG4dUOS0n-UiqT-pqQ_TpY=.8fd7fd34-bb56-4511-a4b7-b6003e12247a@github.com>
Message-ID: <I-aLWJjwkF6-8Imdk8z3ibNq3w-0gGPH3GdqUXUUVg0=.0c3f80a1-81cf-4b0f-a333-e9239859fb9b@github.com>

On Thu, 5 Sep 2024 11:15:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into mismatch-performance2
>>  - Move fill to SegmentBulkOperations
>>  - Add system property and improve benchmark
>>  - Update src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>>  - Remove temp methods
>>  - Clean up
>>  - Update comment
>>  - Merge branch 'master' into mismatch-performance2
>>  - Create a separate class for segment bulk operations
>>  - Add Java implementation of MS::mismatch
>
> test/micro/org/openjdk/bench/java/lang/foreign/Mismatch.java line 87:
> 
>> 85:     }
>> 86: 
>> 87:     @Fork(value = 3, jvmArgsAppend = {"-Djava.lang.foreign.native.threshold.power.mismatch=31"})
> 
> Should we add similar variants to the fill benchmarks?

Good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745340173

From daniel.fuchs at oracle.com  Thu Sep  5 12:11:58 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 5 Sep 2024 13:11:58 +0100
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
Message-ID: <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>

Hi Kim,

On 05/09/2024 06:10, ??? wrote:
> If I use an external lock, T1 will block in the |await()|?state, but T2, 
> T3, and T4 will be waiting for the external lock rather than entering 
> the |await()|?state in |put()|. This would prevent me from simulating 
> the specific behavior I?m trying to test.

I understand. But my point is that waking up callers in exactly the
same order they have have arrived may not be of much interest since you
would need first to ensure that they arrive in exactly that
proper order.

> I?d appreciate your thoughts on whether this behavior (where a newly 
> arriving thread can overtake a waiting thread) is expected or if it?s 
> worth further investigation. As this is my first attempt to contribute 
> to OpenJDK, I?m eager to learn from the process and would love to help 
> resolve the issue if necessary.

I am not sure how strong the "fairness" constraint is.

Typically for monitors, when a thread is signaled after the monitor
is released "it competes in the usual manner with other threads for the 
right to synchronize on the object"
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)

That said, we're speakings of locks here - and the only thing I
could find (in ReentrantLock) is that if fairness is set, then
"under contention, locks favor granting access to the
longest-waiting thread", but note that "fairness of locks does
not guarantee fairness of thread scheduling. Thus, one of many
threads using a fair lock may obtain it multiple times in
succession while other active threads are not progressing and
not currently holding the lock."
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html

I am not an expert of the java.util.concurrent package, and
hopefully others in this list will be able to provide more
insights.

> Also, since English is not my first language, I hope my previous emails 
> didn?t come across as rude or unclear. If they did, I sincerely 
> apologize, as it was never my intention to be disrespectful. I?m still 
> learning how to communicate effectively in this space, and I appreciate 
> your understanding and patience.

Hey - you're welcome - and I found your emails quite clear.
But English is not my first language either ;-)

best regards,

-- daniel

> 
> Thank you for your time and guidance.
> 
> Best regards,
> 


From dholmes at openjdk.org  Thu Sep  5 12:20:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Sep 2024 12:20:52 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v3]
In-Reply-To: <NsQx15dDzClD-cOMpku-iG_fydsHnMtILX0kFtRka6w=.4c996cf7-24a7-4bee-b466-c8bd7854dfd3@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <zygRGCJzlGdAVCN6rTqBI-YsIpHL87WRLqKAgzr6yLM=.9c46f227-6bc5-4411-acb4-ff471dfe5291@github.com>
 <5rZOqWZ627bnEJ66wW7Qqye-ZYeAjsK1083MG5GELLk=.c5c144f0-a1a0-483c-ac21-3a948502c3be@github.com>
 <NsQx15dDzClD-cOMpku-iG_fydsHnMtILX0kFtRka6w=.4c996cf7-24a7-4bee-b466-c8bd7854dfd3@github.com>
Message-ID: <qP2ypgzZGAgPwD24zDCf70oxPxlG0RoTKFxifcfaCt8=.61cddb7b-25ff-4520-9bbf-49a75a7fc3c1@github.com>

On Wed, 4 Sep 2024 11:55:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> It does return. `ShouldNotReachHere` is used to crash the VM.
>
> `fatal()` might be better here. I could change it.

Yes please do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1745356400

From asotona at openjdk.org  Thu Sep  5 12:25:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Sep 2024 12:25:51 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
Message-ID: <MyG1WUJGQxFwOnIU06ZnOX3XmDE_uyL1fCI21PtzuK8=.8761b22c-ed7b-48f5-9e01-8de95e9baaa8@github.com>

On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
> 
> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
> 
> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
> 
> Pinging @wenshao and @cl4es for review.

>From the Class-File API perspective the changes look good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20863#pullrequestreview-2282762266

From pminborg at openjdk.org  Thu Sep  5 12:30:12 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 12:30:12 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v5]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <DJLPeH7K0Kz-ZYp6-xkHKyexLisPtNNLz3vzal1p2e0=.a9cdf8fd-3516-4282-9f51-16f51497e6e8@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Update benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/c421c620..390c1ee3

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

  Stats: 32 lines in 2 files changed: 22 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From pminborg at openjdk.org  Thu Sep  5 13:02:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 13:02:30 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v6]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <Eh_4BrIhoxeF96fpQjv_0omAciU3U-y08FLnwxdaSL4=.181ff607-3662-4d19-bf89-fc3f0245ec55@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Consolidate logic in one method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/390c1ee3..24706141

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

  Stats: 92 lines in 1 file changed: 42 ins; 38 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From pminborg at openjdk.org  Thu Sep  5 13:02:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 13:02:30 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v6]
In-Reply-To: <65LIOx0iXiGTw5PRS01M5_AMiWhpDrU4jd0Fl4ePHi8=.1f877f4f-47ff-4417-9993-b147f8e54de1@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <65LIOx0iXiGTw5PRS01M5_AMiWhpDrU4jd0Fl4ePHi8=.1f877f4f-47ff-4417-9993-b147f8e54de1@github.com>
Message-ID: <-Wd9wDZpCFcYIS3YiXZ0yH8jeueqpJP9lLToU7f1Srg=.00c33909-89d8-415e-8f7c-6ab670577928@github.com>

On Wed, 4 Sep 2024 10:14:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Consolidate logic in one method
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 123:
> 
>> 121:     // This method is intended for 0 <= bytes < 7
>> 122:     @ForceInline
>> 123:     private static long mismatchSmall(AbstractMemorySegmentImpl src, long srcOffset,
> 
> Question. Isn't this:
> 
> 
> // 0...0X00
>             if (remaining >= 4) {
>                 if (SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset) !=
>                         SCOPED_MEMORY_ACCESS.getInt(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset)) {
>                     return mismatchSmall(src, srcFromOffset + offset, dst, dstFromOffset + offset, offset, 4, srcAndDstBytesDiffer);
>                 }
>                 offset += 4;
>                 remaining -= 4;
>             }
>             // 0...00X0
>             if (remaining >= 2) {
>                 if (SCOPED_MEMORY_ACCESS.getShort(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset) !=
>                         SCOPED_MEMORY_ACCESS.getShort(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset)) {
>                     return mismatchSmall(src, srcFromOffset + offset, dst, dstFromOffset + offset, offset, 2, srcAndDstBytesDiffer);
>                 }
>                 offset += 2;
>                 remaining -= 2;
>             }
>             // 0...000X
>             if (remaining == 1) {
>                 if (SCOPED_MEMORY_ACCESS.getByte(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset) !=
>                         SCOPED_MEMORY_ACCESS.getByte(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset)) {
>                     return offset;
>                 }
>             }
> 
> 
> An optimized version of "mismatchSmall" ? Can we reuse the code?

I've managed to do this now that the new optimized bit mismatch finders have removed the need for recursion in such a method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745491738

From pminborg at openjdk.org  Thu Sep  5 13:12:58 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 13:12:58 GMT
Subject: Integrated: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <VMKROGA0KgBABKbf5M6wyoRiVMLb-rqXQj9Yak7GfB4=.4aa8c289-beef-4aa2-b3d6-ed954c46d814@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

This pull request has now been integrated.

Changeset: 6be92726
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6be927260a84b1d7542167e526ff41f7dc26cab0
Stats:     299 lines in 4 files changed: 286 ins; 6 del; 7 mod

8338591: Improve performance of MemorySegment::copy

Reviewed-by: mcimadamore

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

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

From mbaesken at openjdk.org  Thu Sep  5 13:20:11 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Sep 2024 13:20:11 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information [v2]
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <iFlZS7JwKcCNt3Fhq7AYY7NnyezKDbjuIdcwv7xE2Uc=.98a1b51f-2913-4272-8219-cafdefa0b20a@github.com>

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

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

  Repeat sysctl in case of failures;  increase the proc info buffer a bit to hold some more very recent procs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20839/files
  - new: https://git.openjdk.org/jdk/pull/20839/files/a9cd3b25..f344502d

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

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

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

From mbaesken at openjdk.org  Thu Sep  5 13:23:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Sep 2024 13:23:52 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information [v2]
In-Reply-To: <iFlZS7JwKcCNt3Fhq7AYY7NnyezKDbjuIdcwv7xE2Uc=.98a1b51f-2913-4272-8219-cafdefa0b20a@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <iFlZS7JwKcCNt3Fhq7AYY7NnyezKDbjuIdcwv7xE2Uc=.98a1b51f-2913-4272-8219-cafdefa0b20a@github.com>
Message-ID: <M4KEG7MfSUjk4KZsuKfrCyNMeoGvoofhTVCrl2AC-5c=.2661a44a-938a-4593-a74d-152954bf6d8b@github.com>

On Thu, 5 Sep 2024 13:20:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Repeat sysctl in case of failures;  increase the proc info buffer a bit to hold some more very recent procs

Hi Alan, I added a loop and also increased the buffer slightly (from `bufSize`  to  `bufSize + 4 * sizeof(struct kinfo_proc)` ).

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

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2331670817

From sgehwolf at openjdk.org  Thu Sep  5 13:25:17 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 5 Sep 2024 13:25:17 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v6]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <zcnAOfImTlUcaw_Pc2eCr6_5zJvRp4HfNiZ5wHx6B8s=.54bcf23f-f79c-4ded-b692-4589f416b061@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 proposed 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Add JVM_HostActiveProcessorCount using JVM api
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Adjust test and fix code to return lowest hierarchical limit
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Add root check for SystemdMemoryAwarenessTest
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - 8336881: [Linux] Support for hierarchical limits for Metrics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20280/files
  - new: https://git.openjdk.org/jdk/pull/20280/files/7beccf23..5b210068

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

  Stats: 2599 lines in 121 files changed: 2004 ins; 165 del; 430 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 redestad at openjdk.org  Thu Sep  5 13:25:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Sep 2024 13:25:57 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>
Message-ID: <2s_qcI9HpsuvEg-AreraAvJeJWjfx0bgyhU9yrk8V4g=.8bfe724c-13cc-4aeb-94cd-015e89d1dd28@github.com>

On Thu, 5 Sep 2024 06:24:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
>> 
>> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
>> 
>> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
>> 
>> Pinging @wenshao and @cl4es for review.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 235:
> 
>> 233:      * we have a valid opcode.
>> 234:      */
>> 235:     public boolean next() {
> 
> In C1, this cannot be inlined. See if you need to add ForceInline

I don't think we should worry too much about making C1 inline more aggressively.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1745532319

From liach at openjdk.org  Thu Sep  5 13:33:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 13:33:50 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <2s_qcI9HpsuvEg-AreraAvJeJWjfx0bgyhU9yrk8V4g=.8bfe724c-13cc-4aeb-94cd-015e89d1dd28@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>
 <2s_qcI9HpsuvEg-AreraAvJeJWjfx0bgyhU9yrk8V4g=.8bfe724c-13cc-4aeb-94cd-015e89d1dd28@github.com>
Message-ID: <7kMCHcFarzsYb_oJaCh2ho_VpFE92Zn6wvcVDIdqpoE=.c7898ff5-d009-43dd-a5e9-3d4461302991@github.com>

On Thu, 5 Sep 2024 13:22:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 235:
>> 
>>> 233:      * we have a valid opcode.
>>> 234:      */
>>> 235:     public boolean next() {
>> 
>> In C1, this cannot be inlined. See if you need to add ForceInline
>
> I don't think we should worry too much about making C1 inline more aggressively.

C2 needs 10000 calls to inline this method, so wenshao is worried. However, this method call is almost always followed by a huge switch to handle different opcode, so I doubt how much of a difference inlining brings.

But wenshao discovered that this method has too many field gets; I should indeed convert them to local variable access if possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1745548698

From viktor.klang at oracle.com  Thu Sep  5 13:35:04 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 5 Sep 2024 13:35:04 +0000
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
Message-ID: <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi,

I'd also like to add here that Condition::await() is allowed to return spuriously, leading to a reacquisition, and a subsequent release waiting to be woken again, which would change the order from potentially being "next to run" to becoming "last to run". At least this is the case as I read the implementation logic.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Thursday, 5 September 2024 14:11
To: ??? <miiiinju00 at gmail.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim,

On 05/09/2024 06:10, ??? wrote:
> If I use an external lock, T1 will block in the |await()| state, but T2,
> T3, and T4 will be waiting for the external lock rather than entering
> the |await()| state in |put()|. This would prevent me from simulating
> the specific behavior I?m trying to test.

I understand. But my point is that waking up callers in exactly the
same order they have have arrived may not be of much interest since you
would need first to ensure that they arrive in exactly that
proper order.

> I?d appreciate your thoughts on whether this behavior (where a newly
> arriving thread can overtake a waiting thread) is expected or if it?s
> worth further investigation. As this is my first attempt to contribute
> to OpenJDK, I?m eager to learn from the process and would love to help
> resolve the issue if necessary.

I am not sure how strong the "fairness" constraint is.

Typically for monitors, when a thread is signaled after the monitor
is released "it competes in the usual manner with other threads for the
right to synchronize on the object"
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)

That said, we're speakings of locks here - and the only thing I
could find (in ReentrantLock) is that if fairness is set, then
"under contention, locks favor granting access to the
longest-waiting thread", but note that "fairness of locks does
not guarantee fairness of thread scheduling. Thus, one of many
threads using a fair lock may obtain it multiple times in
succession while other active threads are not progressing and
not currently holding the lock."
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html

I am not an expert of the java.util.concurrent package, and
hopefully others in this list will be able to provide more
insights.

> Also, since English is not my first language, I hope my previous emails
> didn?t come across as rude or unclear. If they did, I sincerely
> apologize, as it was never my intention to be disrespectful. I?m still
> learning how to communicate effectively in this space, and I appreciate
> your understanding and patience.

Hey - you're welcome - and I found your emails quite clear.
But English is not my first language either ;-)

best regards,

-- daniel

>
> Thank you for your time and guidance.
>
> Best regards,
>

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

From liach at openjdk.org  Thu Sep  5 13:37:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 13:37:52 GMT
Subject: RFR: 8339592: Simplify and remove unused code in
 ObjectMethods.<clinit>
In-Reply-To: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>
References: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>
Message-ID: <iCsJMC0MRALFShsQsazf2pTo8BpRJ3mdME8BvDr1dGk=.952dd952-5dbd-4484-9528-25d325659d3d@github.com>

On Thu, 5 Sep 2024 08:19:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few trivial(?) cleanups to `java.lang.runtime.ObjectMethods`:
> - Avoid `MethodType.fromMethodDescriptorString` which needs a classloader
> - Use `MethodHandles.zero`
> - Remove unused static `MethodHandles` and `MethodTypes`

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20866#pullrequestreview-2283086658

From redestad at openjdk.org  Thu Sep  5 13:43:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Sep 2024 13:43:50 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <7kMCHcFarzsYb_oJaCh2ho_VpFE92Zn6wvcVDIdqpoE=.c7898ff5-d009-43dd-a5e9-3d4461302991@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>
 <2s_qcI9HpsuvEg-AreraAvJeJWjfx0bgyhU9yrk8V4g=.8bfe724c-13cc-4aeb-94cd-015e89d1dd28@github.com>
 <7kMCHcFarzsYb_oJaCh2ho_VpFE92Zn6wvcVDIdqpoE=.c7898ff5-d009-43dd-a5e9-3d4461302991@github.com>
Message-ID: <htB9PO78y6hbI1emWfQYUCIZyq1zL3mqSjhP89Av6cE=.11364483-2285-4259-90fa-9e98b3b56bf2@github.com>

On Thu, 5 Sep 2024 13:31:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't think we should worry too much about making C1 inline more aggressively.
>
> C2 needs 10000 calls to inline this method, so wenshao is worried. However, this method call is almost always followed by a huge switch to handle different opcode, so I doubt how much of a difference inlining brings.
> 
> But wenshao discovered that this method has too many field gets; I should indeed convert them to local variable access if possible.

Yes, things like storing `endBci()` to a local variable can be great if it both reduces code size and improves interpreter/C1 speed - but don't over-do it as it's likely never-ending work for a kind of optimizations leyden might make pointless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1745564584

From pminborg at openjdk.org  Thu Sep  5 14:00:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 14:00:11 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v7]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <KTlr6H6yKuG2VwZj5fGnUrEyPB2yukMX7WNqk0dmQ8Y=.6a31946f-325a-484e-8c71-cd88f393c71d@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

 - Move method to SegmentBulkOperations and fix benchmark
 - Merge branch 'master' into mismatch-performance2
 - Consolidate logic in one method
 - Update benchmarks
 - Add optimized checking
 - Merge branch 'master' into mismatch-performance2
 - Move fill to SegmentBulkOperations
 - Add system property and improve benchmark
 - Update src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Remove temp methods
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7fea4e9d...5cccbf40

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/24706141..5cccbf40

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

  Stats: 642 lines in 16 files changed: 570 ins; 55 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From miiiinju00 at gmail.com  Thu Sep  5 14:01:19 2024
From: miiiinju00 at gmail.com (=?UTF-8?B?6rmA66+87KO8?=)
Date: Thu, 5 Sep 2024 23:01:19 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>

Hi Viktor, hi Daniel,

Thank you both for your helpful feedback and insightful explanations.

Viktor, your point about Condition::await() and spurious wakeups has given
me a lot to think about. I now better understand why strict FIFO ordering
is challenging, especially given the possibility of spurious wakeups
causing threads to reacquire locks unpredictably.

Daniel, your explanation regarding fairness in locks and how it relates to
thread scheduling has clarified why strict fairness can be difficult to
achieve in practice. It?s especially helpful to know that even with
fairness enabled, other factors can affect thread progression, as explained
in the documentation you provided.

While I understand that these challenges are inherent to multithreading and
some level of unpredictability is inevitable, I?m still wondering whether
it?s appropriate for the implementation to allow new threads attempting to
put() to compete with threads that are already in the await() state. It
feels like this could lead to unintended contention and disruption of
expected behavior. Wouldn't it make more sense to ensure that threads
already blocked in await() have priority over newly arriving threads?

I?m curious to know if you think this approach could be an improvement, or
if this is one of those unavoidable trade-offs in concurrent system design.

Thank you again for your time and expertise. I?m learning a lot through
this process, and I really appreciate your guidance.

Best regards,
Kim Minju

2024? 9? 5? (?) ?? 10:35, Viktor Klang <viktor.klang at oracle.com>?? ??:

> Hi,
>
> I'd also like to add here that Condition::await() is allowed to return
> spuriously, leading to a reacquisition, and a subsequent release waiting to
> be woken again, which would change the order from potentially being "next
> to run" to becoming "last to run". At least this is the case as I read the
> implementation logic.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Daniel Fuchs <daniel.fuchs at oracle.com>
> *Sent:* Thursday, 5 September 2024 14:11
> *To:* ??? <miiiinju00 at gmail.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation
> in BlockingQueue under high contention and suggestion for fair mode in
> ArrayBlockingQueue and LinkedBlockingQueue
>
> Hi Kim,
>
> On 05/09/2024 06:10, ??? wrote:
> > If I use an external lock, T1 will block in the |await()| state, but T2,
> > T3, and T4 will be waiting for the external lock rather than entering
> > the |await()| state in |put()|. This would prevent me from simulating
> > the specific behavior I?m trying to test.
>
> I understand. But my point is that waking up callers in exactly the
> same order they have have arrived may not be of much interest since you
> would need first to ensure that they arrive in exactly that
> proper order.
>
> > I?d appreciate your thoughts on whether this behavior (where a newly
> > arriving thread can overtake a waiting thread) is expected or if it?s
> > worth further investigation. As this is my first attempt to contribute
> > to OpenJDK, I?m eager to learn from the process and would love to help
> > resolve the issue if necessary.
>
> I am not sure how strong the "fairness" constraint is.
>
> Typically for monitors, when a thread is signaled after the monitor
> is released "it competes in the usual manner with other threads for the
> right to synchronize on the object"
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)
>
> That said, we're speakings of locks here - and the only thing I
> could find (in ReentrantLock) is that if fairness is set, then
> "under contention, locks favor granting access to the
> longest-waiting thread", but note that "fairness of locks does
> not guarantee fairness of thread scheduling. Thus, one of many
> threads using a fair lock may obtain it multiple times in
> succession while other active threads are not progressing and
> not currently holding the lock."
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html
>
> I am not an expert of the java.util.concurrent package, and
> hopefully others in this list will be able to provide more
> insights.
>
> > Also, since English is not my first language, I hope my previous emails
> > didn?t come across as rude or unclear. If they did, I sincerely
> > apologize, as it was never my intention to be disrespectful. I?m still
> > learning how to communicate effectively in this space, and I appreciate
> > your understanding and patience.
>
> Hey - you're welcome - and I found your emails quite clear.
> But English is not my first language either ;-)
>
> best regards,
>
> -- daniel
>
> >
> > Thank you for your time and guidance.
> >
> > Best regards,
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/23276430/attachment-0001.htm>

From swen at openjdk.org  Thu Sep  5 14:06:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 14:06:50 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <htB9PO78y6hbI1emWfQYUCIZyq1zL3mqSjhP89Av6cE=.11364483-2285-4259-90fa-9e98b3b56bf2@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>
 <2s_qcI9HpsuvEg-AreraAvJeJWjfx0bgyhU9yrk8V4g=.8bfe724c-13cc-4aeb-94cd-015e89d1dd28@github.com>
 <7kMCHcFarzsYb_oJaCh2ho_VpFE92Zn6wvcVDIdqpoE=.c7898ff5-d009-43dd-a5e9-3d4461302991@github.com>
 <htB9PO78y6hbI1emWfQYUCIZyq1zL3mqSjhP89Av6cE=.11364483-2285-4259-90fa-9e98b3b56bf2@github.com>
Message-ID: <bMWuAQUsM5-IqqjKhiDDxmDcjJpbC5cpKXMv7_6O1SM=.97acd7c4-9c7f-4a22-9162-525aca3b5cb9@github.com>

On Thu, 5 Sep 2024 13:40:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> C2 needs 10000 calls to inline this method, so wenshao is worried. However, this method call is almost always followed by a huge switch to handle different opcode, so I doubt how much of a difference inlining brings.
>> 
>> But wenshao discovered that this method has too many field gets; I should indeed convert them to local variable access if possible.
>
> Yes, things like storing `endBci()` to a local variable can be great if it both reduces code size and improves interpreter/C1 speed - but don't over-do it as it's likely never-ending work for a kind of optimizations leyden might make pointless.

It is not necessary to use RawBytecodeHelper in the StackMapGenerator#detectFrameOffsets method. It may be better to operate directly on the `byte[] bytecode`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1745608455

From alanb at openjdk.org  Thu Sep  5 14:25:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 14:25:54 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
Message-ID: <idiDi_KpXcn4OjrHe7OzxHf25luZWVbasOEJVRRb6T4=.5279c9df-4ee9-4245-abb3-7688439e4505@github.com>

On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
>> 
>> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
>> 
>> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
>> 
>> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
>> 
>> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
>> 
>> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20854#pullrequestreview-2283229031

From epeter at openjdk.org  Thu Sep  5 14:28:58 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 5 Sep 2024 14:28:58 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v7]
In-Reply-To: <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>
Message-ID: <_aU7H3hhe2lA5cwndBuEFJ8U2rahyKwm60xqXaIANTQ=.1f027324-95d1-4539-b094-7ac04608fe59@github.com>

On Thu, 5 Sep 2024 08:34:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some cleanups.

No time to review now. But the title only talks about saturating vector operations. UMin/ UMax is not really a saturating operation, right? Preferably, move it to a separate PR, or at least change the title, please :)

Just note on the length of this PR: people are not really excited to review 9k lines at once. I personally spend quite a bit of effort splitting things into smaller units, so that I get things reviewed quicker, and so that I make the life of the reviewer easier. It would be nice if you could split things into smaller units, I think in the end you would get more reviews quicker, and the result would be of higher quality.

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

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2331828999

From epeter at openjdk.org  Thu Sep  5 14:47:55 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 5 Sep 2024 14:47:55 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v7]
In-Reply-To: <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>
Message-ID: <kdiE57Wre-w-95zW4cgbsLEfYhdKWt-Fpfk8WOWDxbE=.456c5a1b-9077-40f4-9e10-01c9fcf5cdf4@github.com>

On Thu, 5 Sep 2024 08:34:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some cleanups.

Just a few quick remarks.

src/hotspot/share/opto/vectornode.hpp line 188:

> 186: };
> 187: 
> 188: 

Suprious newline, please remove
Suggestion:

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathUtils.java line 78:

> 76:      * @since 24
> 77:      */
> 78:     public static long addSaturating(long a, long b) {

Are these public methods any Java dev could use? If so: do we have tests for them?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2283248252
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1745655940
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1745665600

From epeter at openjdk.org  Thu Sep  5 14:47:56 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 5 Sep 2024 14:47:56 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v5]
In-Reply-To: <7huBzF7ygKcr1ADKYTizGsyEBNb6dWYaU3g9_StUGB4=.89495de4-e6b5-47d6-9756-41471d366211@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
 <TQRt9w38cIX-gRkjVANWp0aZU5mNwcU95R09ISuTo7c=.4de988d2-bd8b-43fe-9b0c-15821f82d5e0@github.com>
 <7huBzF7ygKcr1ADKYTizGsyEBNb6dWYaU3g9_StUGB4=.89495de4-e6b5-47d6-9756-41471d366211@github.com>
Message-ID: <QX4ZEYwJYbG8EE3XnceLhmKEJS1hbq3c8ULpVyEoWDY=.62ec2239-e548-4335-8d85-235afa742dd4@github.com>

On Thu, 5 Sep 2024 07:42:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.hpp line 634:
>> 
>>> 632:   virtual int Opcode() const;
>>> 633: };
>>> 634: 
>> 
>> This could also be a separate PR. Or are they somehow inseparable from the "saturation" changes?
>
> Not applicable now.

What is not applicable? Do you actually need this node for the saturating operations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1745661230

From bpb at openjdk.org  Thu Sep  5 15:06:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Sep 2024 15:06:56 GMT
Subject: Integrated: 8003887: File.getCanonicalFile() does not resolve symlinks
 on MS Windows
In-Reply-To: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
Message-ID: <6yIXVlKhAW_ntIfd80UoVqXF48zLHLOe-mICj0cffeY=.bc336f6c-1e30-4c62-97e4-60a0c9bcaf3e@github.com>

On Fri, 30 Aug 2024 20:59:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Return the final path derived from the string returned by `canonicalize0()`.

This pull request has now been integrated.

Changeset: 042053c3
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/042053c3a82e9fbd4c6866efe872c1c92714e6e7
Stats:     147 lines in 3 files changed: 121 ins; 20 del; 6 mod

8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows

Reviewed-by: alanb

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

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

From liach at openjdk.org  Thu Sep  5 15:27:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 15:27:50 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <bMWuAQUsM5-IqqjKhiDDxmDcjJpbC5cpKXMv7_6O1SM=.97acd7c4-9c7f-4a22-9162-525aca3b5cb9@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <tCO_1THaQh8o-4zM_lNUDeBLVNDyqwYP8qGgIl2y12c=.75b8fb29-e48b-4001-87d0-9a975200b7c8@github.com>
 <2s_qcI9HpsuvEg-AreraAvJeJWjfx0bgyhU9yrk8V4g=.8bfe724c-13cc-4aeb-94cd-015e89d1dd28@github.com>
 <7kMCHcFarzsYb_oJaCh2ho_VpFE92Zn6wvcVDIdqpoE=.c7898ff5-d009-43dd-a5e9-3d4461302991@github.com>
 <htB9PO78y6hbI1emWfQYUCIZyq1zL3mqSjhP89Av6cE=.11364483-2285-4259-90fa-9e98b3b56bf2@github.com>
 <bMWuAQUsM5-IqqjKhiDDxmDcjJpbC5cpKXMv7_6O1SM=.97acd7c4-9c7f-4a22-9162-525aca3b5cb9@github.com>
Message-ID: <lHFO6AdqdXcx_QO6qygxX2uCNJpfMPm8J56eXCte2j8=.3736336f-da07-45b4-bf3a-96c44ad835b4@github.com>

On Thu, 5 Sep 2024 14:04:19 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Yes, things like storing `endBci()` to a local variable can be great if it both reduces code size and improves interpreter/C1 speed - but don't over-do it as it's likely never-ending work for a kind of optimizations leyden might make pointless.
>
> It is not necessary to use RawBytecodeHelper in the StackMapGenerator#detectFrameOffsets method. It may be better to operate directly on the `byte[] bytecode`.

We could have just tracked the offsets when labels from DirectCodeBuilder are bound; we can explore such a fix in another patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20863#discussion_r1745759169

From viktor.klang at oracle.com  Thu Sep  5 15:36:20 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 5 Sep 2024 15:36:20 +0000
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
Message-ID: <MW4PR10MB577428F3DB4C3C7D8736ACF7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Kim,

I'll add some of my personal thoughts on the matter.

What you're typically after when you're reaching for "fair" is not a strict linearizable order (because such order needs external, additional, coordination to be observable), but rather what you want is to avoid the risk of "unbounded unfairness", I'll give an example:

Think of a drinking glass cabinet: If you always put back glasses in front of other glasses when they have been used and cleaned, and you always get glasses from the front?given sufficient number of glasses compared to your glass-needs, you're going to end up with the glasses at the very front showing significant signs of usage where the ones at the back will be brand new and unused.

Or more succinctly: stack-based access patterns easily lead to logarithmic-like usage distributions.

With this in mind, it would be interesting (at least to me!) if you could devise a test which can demonstrate that the "fair" mode of ABQ can lead to unbounded unfairness.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: ??? <miiiinju00 at gmail.com>
Sent: Thursday, 5 September 2024 16:01
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue


Hi Viktor, hi Daniel,

Thank you both for your helpful feedback and insightful explanations.

Viktor, your point about Condition::await() and spurious wakeups has given me a lot to think about. I now better understand why strict FIFO ordering is challenging, especially given the possibility of spurious wakeups causing threads to reacquire locks unpredictably.

Daniel, your explanation regarding fairness in locks and how it relates to thread scheduling has clarified why strict fairness can be difficult to achieve in practice. It?s especially helpful to know that even with fairness enabled, other factors can affect thread progression, as explained in the documentation you provided.

While I understand that these challenges are inherent to multithreading and some level of unpredictability is inevitable, I?m still wondering whether it?s appropriate for the implementation to allow new threads attempting to put() to compete with threads that are already in the await() state. It feels like this could lead to unintended contention and disruption of expected behavior. Wouldn't it make more sense to ensure that threads already blocked in await() have priority over newly arriving threads?

I?m curious to know if you think this approach could be an improvement, or if this is one of those unavoidable trade-offs in concurrent system design.

Thank you again for your time and expertise. I?m learning a lot through this process, and I really appreciate your guidance.

Best regards,
Kim Minju

2024? 9? 5? (?) ?? 10:35, Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>?? ??:
Hi,

I'd also like to add here that Condition::await() is allowed to return spuriously, leading to a reacquisition, and a subsequent release waiting to be woken again, which would change the order from potentially being "next to run" to becoming "last to run". At least this is the case as I read the implementation logic.

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 Daniel Fuchs <daniel.fuchs at oracle.com<mailto:daniel.fuchs at oracle.com>>
Sent: Thursday, 5 September 2024 14:11
To: ??? <miiiinju00 at gmail.com<mailto:miiiinju00 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: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim,

On 05/09/2024 06:10, ??? wrote:
> If I use an external lock, T1 will block in the |await()| state, but T2,
> T3, and T4 will be waiting for the external lock rather than entering
> the |await()| state in |put()|. This would prevent me from simulating
> the specific behavior I?m trying to test.

I understand. But my point is that waking up callers in exactly the
same order they have have arrived may not be of much interest since you
would need first to ensure that they arrive in exactly that
proper order.

> I?d appreciate your thoughts on whether this behavior (where a newly
> arriving thread can overtake a waiting thread) is expected or if it?s
> worth further investigation. As this is my first attempt to contribute
> to OpenJDK, I?m eager to learn from the process and would love to help
> resolve the issue if necessary.

I am not sure how strong the "fairness" constraint is.

Typically for monitors, when a thread is signaled after the monitor
is released "it competes in the usual manner with other threads for the
right to synchronize on the object"
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Object.html#wait(long,int)

That said, we're speakings of locks here - and the only thing I
could find (in ReentrantLock) is that if fairness is set, then
"under contention, locks favor granting access to the
longest-waiting thread", but note that "fairness of locks does
not guarantee fairness of thread scheduling. Thus, one of many
threads using a fair lock may obtain it multiple times in
succession while other active threads are not progressing and
not currently holding the lock."
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html

I am not an expert of the java.util.concurrent package, and
hopefully others in this list will be able to provide more
insights.

> Also, since English is not my first language, I hope my previous emails
> didn?t come across as rude or unclear. If they did, I sincerely
> apologize, as it was never my intention to be disrespectful. I?m still
> learning how to communicate effectively in this space, and I appreciate
> your understanding and patience.

Hey - you're welcome - and I found your emails quite clear.
But English is not my first language either ;-)

best regards,

-- daniel

>
> Thank you for your time and guidance.
>
> Best regards,
>

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

From liach at openjdk.org  Thu Sep  5 15:39:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 15:39:07 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
 [v2]
In-Reply-To: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
Message-ID: <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>

> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
> 
> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
> 
> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
> 
> Pinging @wenshao and @cl4es for review.

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

  Avoid repeated field usage, eliminate bound checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20863/files
  - new: https://git.openjdk.org/jdk/pull/20863/files/59a95339..a8b9a820

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

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

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

From jvernee at openjdk.org  Thu Sep  5 16:04:08 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 5 Sep 2024 16:04:08 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v4]
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <I-u9iiCEx04UTye6cIYGIHl4We3DnmdkfYCrSFdGVW4=.359a6990-f851-462e-b9e3-360dbb959267@github.com>

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

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

  use fatal()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20479/files
  - new: https://git.openjdk.org/jdk/pull/20479/files/1558ad9c..7d191107

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

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

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

From amitkumar at openjdk.org  Thu Sep  5 16:08:52 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 5 Sep 2024 16:08:52 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v4]
In-Reply-To: <snjODYeKBUua5UmNQrNxteFUdQp_0w5ehUCU29T2lBU=.73abe450-2870-4f4d-bd0d-d464278daf26@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <lgttiVGFH9LgYzOGqlvbjJyimVAGjzMqcx56gQNS3pE=.433730d3-589a-488d-8bf0-225ff181f292@github.com>
 <XbGJQepek4rosScV7wy6rAsmHdxKD-THK3HLOT35afQ=.4bd3a95d-c30d-4a4c-8c14-eaed8ec48080@github.com>
 <xKd0prUFEvSHZOQojM578jthD0VYbsF0lKt5Hcn40iQ=.917ef4a3-c357-4e5d-b2e3-d71dbc24444c@github.com>
 <snjODYeKBUua5UmNQrNxteFUdQp_0w5ehUCU29T2lBU=.73abe450-2870-4f4d-bd0d-d464278daf26@github.com>
Message-ID: <CKxv52ixmfDs206iVsbu-Wvpi07CMhttpIvyE9EkU9k=.abdae2fc-874a-4b87-b59d-3f15106be897@github.com>

On Wed, 4 Sep 2024 17:03:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tier1 test are fine with/without "saving & restoring" return_pc;
>
> I found it: https://github.com/openjdk/jdk/blob/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7/src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp#L238
> Called here:
> https://github.com/openjdk/jdk/blob/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7/src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp#L115
> Other GCs with load barriers are not implemented, so the save&restore code is redundant.
> The stub is frameless and only needs the save&restore code when calling C.
> In this case, no weak references are used, so there's no C call on s390.

@JornVernee would you please remove "saving & restoring" code for the return PC as mentioned by Martin. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1745819490

From archie.cobbs at gmail.com  Thu Sep  5 16:44:37 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 5 Sep 2024 11:44:37 -0500
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
Message-ID: <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>

Hi Kim,

I think there may be an issue with your test. Specifically, this code is
suspect:

    // Wait for the producer thread to enter BLOCKED state
    // This ensures that the thread is waiting on the full queue
    while (thread.getState() == State.RUNNABLE || thread.getState() ==
State.NEW);

I don't think that actually guarantees that the thread is blocked in put().

I was able to reproduce the bug using ArrayBlockingQueue(), but could no
longer reproduce it after I changed the above code to this:

    // Wait for the producer thread to block in queue.put()
    // This ensures that the thread is waiting on the full queue
    while (!queue.isPutting(thread));

after also making this change to ArrayBlockingQueue.java:

---
a/src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
+++
b/src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
@@ -365,10 +365,31 @@ public void put(E e) throws InterruptedException {
         Objects.requireNonNull(e);
         final ReentrantLock lock = this.lock;
         lock.lockInterruptibly();
+        final boolean added = puttingThreads.add(Thread.currentThread());
         try {
             while (count == items.length)
                 notFull.await();
             enqueue(e);
+        } finally {
+            if (added)
+                puttingThreads.remove(Thread.currentThread());
+            lock.unlock();
+        }
+    }
+
+    private final java.util.HashSet<Thread> puttingThreads = new
java.util.HashSet<>();
+
+    /**
+     * Test for putting thread.
+     *
+     * @param thread thread to test
+     * @return true if thread is a putting thread
+     */
+    public boolean isPutting(Thread thread) {
+        final ReentrantLock lock = this.lock;
+        lock.lock();
+        try {
+            return puttingThreads.contains(thread);
         } finally {
             lock.unlock();
         }

So the original test may not be correct due to Java memory model
subtleties, etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/c7d0db3c/attachment-0001.htm>

From redestad at openjdk.org  Thu Sep  5 17:07:51 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Sep 2024 17:07:51 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
 [v2]
In-Reply-To: <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>
Message-ID: <Ujp9rAR8uB8z7ZCd8QJabzK_xJKDNKlt9nL2wY_6AJk=.a329886b-cec8-4260-9c79-2c9970cd5d06@github.com>

On Thu, 5 Sep 2024 15:39:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
>> 
>> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
>> 
>> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
>> 
>> Pinging @wenshao and @cl4es for review.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid repeated field usage, eliminate bound checks

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20863#pullrequestreview-2283641297

From pminborg at openjdk.org  Thu Sep  5 17:21:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 17:21:32 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v8]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <Q0qe8x4p1xailb4WLExHT0KdtUAouxg-nVZGW7ZoHN4=.6ad87000-963e-4223-b810-d6622f5ffe0f@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Lower the mismatch threshold

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/5cccbf40..dc9ad11a

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

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

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

From mcimadamore at openjdk.org  Thu Sep  5 17:40:54 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 17:40:54 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v8]
In-Reply-To: <Q0qe8x4p1xailb4WLExHT0KdtUAouxg-nVZGW7ZoHN4=.6ad87000-963e-4223-b810-d6622f5ffe0f@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <Q0qe8x4p1xailb4WLExHT0KdtUAouxg-nVZGW7ZoHN4=.6ad87000-963e-4223-b810-d6622f5ffe0f@github.com>
Message-ID: <HjXgHxwasXnSr4APjJP8XFUfMo4Kny6qnvwSoXvzCHE=.281e0a2f-e30f-45cb-8180-97b729533afb@github.com>

On Thu, 5 Sep 2024 17:21:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower the mismatch threshold

test/micro/org/openjdk/bench/java/lang/foreign/TestMismatch.java line 91:

> 89:     @Benchmark
> 90:     public long heapSegmentJava() {
> 91:         return srcNative.mismatch(dstNative);

this should use heap segments

test/micro/org/openjdk/bench/java/lang/foreign/TestMismatch.java line 103:

> 101:     @Benchmark
> 102:     public long heapSegmentUnsafe() {
> 103:         return srcNative.mismatch(dstNative);

this should use heap segments

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745930749
PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745930965

From pminborg at openjdk.org  Thu Sep  5 17:47:16 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Sep 2024 17:47:16 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Fix errors in a benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/dc9ad11a..e8d7777c

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

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

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

From mcimadamore at openjdk.org  Thu Sep  5 17:53:56 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 17:53:56 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
Message-ID: <k9YKNmPqzfp9CuOWgvklilmTVVv6ibBUXU3Jj1BwEOQ=.5f30c9ed-3aa5-46ad-83a9-3e0cfc248aee@github.com>

On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errors in a benchmark

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 175:

> 173:         } else {
> 174:             long i;
> 175:             if (SCOPED_MEMORY_ACCESS.getByte(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset) !=

I looked at this the other day, and I couldn't immediately tell whether this test is needed or not - shouldn't it be covered by the subsequent loop? Is it a shortcut (but only for the first element) - how much does that buy really?

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 179:

> 177:                 return 0;
> 178:             }
> 179:             i = AbstractMemorySegmentImpl.vectorizedMismatchLargeForBytes(src.sessionImpl(), dst.sessionImpl(),

We should probably move `vectorizedMismatchLargeForBytes` in this class too, for clarity

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745946359
PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745944712

From alanb at openjdk.org  Thu Sep  5 17:54:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 17:54:46 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v3]
In-Reply-To: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
Message-ID: <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>

> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html) and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
> 
> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
> 
> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
> 
> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).

Alan Bateman 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:

 - Sync up from loom repo
 - Merge
 - Sync up from loom repo
 - Merge
 - Sync up from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20816/files
  - new: https://git.openjdk.org/jdk/pull/20816/files/1ce1a6ac..189d5467

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

  Stats: 2610 lines in 145 files changed: 1698 ins; 576 del; 336 mod
  Patch: https://git.openjdk.org/jdk/pull/20816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20816/head:pull/20816

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

From mcimadamore at openjdk.org  Thu Sep  5 17:57:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 17:57:51 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
Message-ID: <qy_HpSbuk1dc1VCUuW0D3lGOME1lDaHgV4zyT8I6QD0=.400d6c36-96a1-4465-bab0-f545e9325dcb@github.com>

On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errors in a benchmark

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 242:

> 240:     private static int mismatch(long first, long second) {
> 241:         final long x = first ^ second;
> 242:         return (Architecture.isLittleEndian()

clever!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745949897

From mcimadamore at openjdk.org  Thu Sep  5 18:00:53 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 18:00:53 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
Message-ID: <Y0YYrjRsgqImAAGTQcTRvIov-GM7MGhpePAsujcNAN8=.db2d6c56-1a8a-45e1-8d33-0021eee11fa6@github.com>

On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errors in a benchmark

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 211:

> 209:             final int s = SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset);
> 210:             final int d = SCOPED_MEMORY_ACCESS.getInt(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset);
> 211:             if (s != d) {

Can we run `mismatch(s, d)` and then check the returned index (e.g. `!= 0`) instead of doing a full comparison and then another mismatch? Or is that slower?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745954081

From duke at openjdk.org  Thu Sep  5 18:02:54 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 5 Sep 2024 18:02:54 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v3]
In-Reply-To: <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
 <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>
Message-ID: <di0QgwZ-BSC7JnvG_kQwdFKclXlZ3qCRRzyuzwnm6nI=.41531932-ff32-4f17-9b71-4f2c2f35a364@github.com>

On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html) and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
>> 
>> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
>> 
>> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
>> 
>> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).
>
> Alan Bateman 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:
> 
>  - Sync up from loom repo
>  - Merge
>  - Sync up from loom repo
>  - Merge
>  - Sync up from loom repo
>  - Initial commit

src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 114:

> 112:                 case ForkJoinPool pool -> pool.getParallelism();
> 113:                 case ThreadPoolExecutor pool -> pool.getMaximumPoolSize();
> 114:                 default -> -1;

The API docs don't seem to specify what a value of `-1` means; is it meant to indicate "not known"? It seems like other implementations are returning e.g. `MAX_VALUE` sometimes too; is that worth calling out in the doc for `getParallelism()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1745955917

From mcimadamore at openjdk.org  Thu Sep  5 18:06:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 18:06:51 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
Message-ID: <T_tAXxPgQDJ8foBCX6xzRQ-AXdwQxvQUzvAHXQfE-mg=.afb60060-0c76-444f-b349-e35bf17355bc@github.com>

On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errors in a benchmark

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 76:

> 74:             final int limit = (int) (dst.length & (NATIVE_THRESHOLD_FILL - 8));
> 75:             for (; offset < limit; offset += 8) {
> 76:                 SCOPED_MEMORY_ACCESS.putLong(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + offset, longValue);

Now that I look again at this - I think all these calls should use `putXYZUnaligned`. Otherwise alignment can introduce issues on some platforms. That will call an `Unsafe` intrinsics that will do the best possible job at serving a potentially unaligned request. This is, btw, what we use when we do e.g. `segment.get(JAVA_LONG, offset)`. Since you are using a lower-level API here, you need to make sure you use the correct memory access primitive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745959346

From liach at openjdk.org  Thu Sep  5 18:11:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 18:11:26 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v4]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <uY6SZueI4GhHBDH1-2FZsaOonJyr_lKmZqNmYSKRSDk=.b3a8fc7f-dec5-41a1-bac4-13578a756197@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Rename constants at new locations, link to related factories, cp tag constant names
 - Fix compile errors
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Compile errors; now tests are all green.
 - Move Constant Pool tags to PoolEntry
   
   Two unexpected usages in jlink raw processing, but rest is fine
 - opcode values moved to OpcodeValues
   
   less impactful than imagined, no longer need to qualify Opcode use when star importing ClassFile
 - Hide default class flags as well
 - ... and 2 more: https://git.openjdk.org/jdk/compare/48d79431...bbeff620

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

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=03
  Stats: 3471 lines in 37 files changed: 1563 ins; 905 del; 1003 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

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

From mcimadamore at openjdk.org  Thu Sep  5 18:11:58 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 18:11:58 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <T_tAXxPgQDJ8foBCX6xzRQ-AXdwQxvQUzvAHXQfE-mg=.afb60060-0c76-444f-b349-e35bf17355bc@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
 <T_tAXxPgQDJ8foBCX6xzRQ-AXdwQxvQUzvAHXQfE-mg=.afb60060-0c76-444f-b349-e35bf17355bc@github.com>
Message-ID: <LNP1r6MeCyewHk2cnBl6poQw0CEhQ1qFC4svfEjLHBo=.7645d72f-a238-4bcd-8c80-89332a204313@github.com>

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

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix errors in a benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 76:
> 
>> 74:             final int limit = (int) (dst.length & (NATIVE_THRESHOLD_FILL - 8));
>> 75:             for (; offset < limit; offset += 8) {
>> 76:                 SCOPED_MEMORY_ACCESS.putLong(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + offset, longValue);
> 
> Now that I look again at this - I think all these calls should use `putXYZUnaligned`. Otherwise alignment can introduce issues on some platforms. That will call an `Unsafe` intrinsics that will do the best possible job at serving a potentially unaligned request. This is, btw, what we use when we do e.g. `segment.get(JAVA_LONG, offset)`. Since you are using a lower-level API here, you need to make sure you use the correct memory access primitive.

This tactic should be reflected in a top-level comment in this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745966605

From mcimadamore at openjdk.org  Thu Sep  5 18:14:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 18:14:00 GMT
Subject: Integrated: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames
In-Reply-To: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
Message-ID: <JdKe7fXuFFyFL2dy5gpSZ9PEUox1GOMzL9joA8hxvNk=.b1e4fd54-6bb0-4450-beda-fb0fbe54e2a3@github.com>

On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
> 
> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
> 
> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
> 
> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
> 
> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
> 
> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

This pull request has now been integrated.

Changeset: 9e1af8cc
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e1af8cc7cc9f63453097bd35eb3cf29f945d765
Stats:     253 lines in 9 files changed: 212 ins; 12 del; 29 mod

8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Thu Sep  5 18:24:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 18:24:51 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v3]
In-Reply-To: <di0QgwZ-BSC7JnvG_kQwdFKclXlZ3qCRRzyuzwnm6nI=.41531932-ff32-4f17-9b71-4f2c2f35a364@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
 <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>
 <di0QgwZ-BSC7JnvG_kQwdFKclXlZ3qCRRzyuzwnm6nI=.41531932-ff32-4f17-9b71-4f2c2f35a364@github.com>
Message-ID: <2aIUNAV0eK4hN06cqgqnwaZxbTql5VdSzWYNuXmT480=.1cde11f8-ba1d-462f-b653-cf7ceb180dde@github.com>

On Thu, 5 Sep 2024 17:59:50 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The API docs don't seem to specify what a value of `-1` means; is it meant to indicate "not known"? It seems like other implementations are returning e.g. `MAX_VALUE` sometimes too; is that worth calling out in the doc for `getParallelism()`?

That can't happen right now as there is no support for configuring a different virtual thread scheduler in main line. So this could throw an "should not reach here" Error. If we were to expose something then it would include a side channel to obtain the management interface for that scheduler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1745980908

From duke at openjdk.org  Thu Sep  5 18:37:56 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Thu, 5 Sep 2024 18:37:56 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <C1wi9FmMvN9_vFPTcgKirtA6CWnuZXt-nVWkIhRsenc=.cf5e1e90-a14d-4c9d-bf69-66c5c2f8b465@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

Wdyt about the benchmark I have added at https://github.com/openjdk/jdk/pull/20829#issuecomment-2326404582? 
Sadly I didn't yet run against this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/20829#issuecomment-2332396566

From alanb at openjdk.org  Thu Sep  5 18:51:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 18:51:51 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information [v2]
In-Reply-To: <iFlZS7JwKcCNt3Fhq7AYY7NnyezKDbjuIdcwv7xE2Uc=.98a1b51f-2913-4272-8219-cafdefa0b20a@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <iFlZS7JwKcCNt3Fhq7AYY7NnyezKDbjuIdcwv7xE2Uc=.98a1b51f-2913-4272-8219-cafdefa0b20a@github.com>
Message-ID: <HBR-WZVIpQlNbljsz44xXYc8wmHPPLp3Q1-cq8c3LfM=.0e2f39e1-70cf-4c4c-bde7-fb6bc4e6b4bf@github.com>

On Thu, 5 Sep 2024 13:20:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Repeat sysctl in case of failures;  increase the proc info buffer a bit to hold some more very recent procs

src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c line 124:

> 122:         // Read process info for all processes
> 123:         errsysctl = sysctl(mib, 4, buffer, &bufSize, NULL, 0);
> 124:     } while (errsysctl < 0 && maxRetries-- > 0);

Using a loop is good but I assume only when the second sysctl fails with errno=ENOMEM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20839#discussion_r1746012053

From liach at openjdk.org  Thu Sep  5 19:03:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 19:03:07 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v5]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <tV8zUU647jC8W5aq4kSmTofsOEB16OxHpsxVm92Bd9Q=.73f3e3ba-eb7d-4e31-acfb-4b1ac4817684@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

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

  omission in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20773/files
  - new: https://git.openjdk.org/jdk/pull/20773/files/bbeff620..39c28f39

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

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

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

From viktor.klang at oracle.com  Thu Sep  5 19:05:14 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 5 Sep 2024 19:05:14 +0000
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
Message-ID: <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>

Good point, Archie?I completely forgot to mention the fact that polling thread state doesn't necessarily ensure that the thread has been enqueued once the thread state is moved to blocking/waiting.

Thread state polling aside, for as long as Condition::await() is allowed to spuriously wake, FIFO just cannot be "guaranteed".

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Archie Cobbs <archie.cobbs at gmail.com>
Sent: Thursday, 5 September 2024 18:44
To: ??? <miiiinju00 at gmail.com>
Cc: Viktor Klang <viktor.klang at oracle.com>; Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim,

I think there may be an issue with your test. Specifically, this code is suspect:

    // Wait for the producer thread to enter BLOCKED state
    // This ensures that the thread is waiting on the full queue
    while (thread.getState() == State.RUNNABLE || thread.getState() == State.NEW);

I don't think that actually guarantees that the thread is blocked in put().

I was able to reproduce the bug using ArrayBlockingQueue(), but could no longer reproduce it after I changed the above code to this:

    // Wait for the producer thread to block in queue.put()
    // This ensures that the thread is waiting on the full queue
    while (!queue.isPutting(thread));

after also making this change to ArrayBlockingQueue.java:

--- a/src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
+++ b/src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
@@ -365,10 +365,31 @@ public void put(E e) throws InterruptedException {
         Objects.requireNonNull(e);
         final ReentrantLock lock = this.lock;
         lock.lockInterruptibly();
+        final boolean added = puttingThreads.add(Thread.currentThread());
         try {
             while (count == items.length)
                 notFull.await();
             enqueue(e);
+        } finally {
+            if (added)
+                puttingThreads.remove(Thread.currentThread());
+            lock.unlock();
+        }
+    }
+
+    private final java.util.HashSet<Thread> puttingThreads = new java.util.HashSet<>();
+
+    /**
+     * Test for putting thread.
+     *
+     * @param thread thread to test
+     * @return true if thread is a putting thread
+     */
+    public boolean isPutting(Thread thread) {
+        final ReentrantLock lock = this.lock;
+        lock.lock();
+        try {
+            return puttingThreads.contains(thread);
         } finally {
             lock.unlock();
         }

So the original test may not be correct due to Java memory model subtleties, etc.

-Archie

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/da8fc270/attachment-0001.htm>

From duke at openjdk.org  Thu Sep  5 19:10:34 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 5 Sep 2024 19:10:34 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v3]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <fiTWbCHS_pL8gkbMwSW9pLSzPhVD3TIAhiPxxM-E38A=.a191f89e-8a98-4ca5-bf7e-87bfb9009300@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  update libm tanh reference test with code review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/4739ad45..39350a37

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

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

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

From duke at openjdk.org  Thu Sep  5 19:10:34 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 5 Sep 2024 19:10:34 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <wK4G7LUS-Gok7NQkrOLtTQ5_CKBsItY5TFFBATdnRcE=.2ea606e1-ad67-44ed-b875-3f45483a0b6c@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <wK4G7LUS-Gok7NQkrOLtTQ5_CKBsItY5TFFBATdnRcE=.2ea606e1-ad67-44ed-b875-3f45483a0b6c@github.com>
Message-ID: <cbzd2DAIE5tUOcnXWkYnIUgT4P5wdv3_jjleAsCJL3w=.e52abf92-8249-4a55-840d-9bfb784bbd15@github.com>

On Tue, 3 Sep 2024 22:55:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add stub initialization and extra tanh tests
>
> test/jdk/java/lang/Math/HyperbolicTests.java line 984:
> 
>> 982:         double b1 = 0.02;
>> 983:         double b2 = 5.1;
>> 984:         double b3 = 55 * Math.log(2)/2; // ~19.062
> 
> Probably better to use StrictMath.log here or, better use, precompute the value as a constant and document its conceptual origin.

Please see the updated code which uses the precomputed value of `b3`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1746031432

From duke at openjdk.org  Thu Sep  5 19:12:55 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 5 Sep 2024 19:12:55 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
Message-ID: <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>

On Wed, 4 Sep 2024 00:01:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> If the test is going to use randomness, then its jtreg tags should include
> 
> `@key randomness`
> 
> and it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.

Please see the test updated to use `@key randomness` and` jdk.test.lib.RandomFactory` to get and Random object.

> The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.
> For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).
>
So far the tests haven't failed with error of 2.5ulp. Would it be better to make it 5ulp? Please let me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1746034895

From jiangli at openjdk.org  Thu Sep  5 19:21:52 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 19:21:52 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <7tmo9e9RcUi06DYLjvQEaEu_XCY4bUa4OcWByw7vCdc=.11672bb7-71ca-46f4-8ed1-48512ab59e15@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <7tmo9e9RcUi06DYLjvQEaEu_XCY4bUa4OcWByw7vCdc=.11672bb7-71ca-46f4-8ed1-48512ab59e15@github.com>
Message-ID: <lMsYEHY3jMzn6jizRTPmcUpmp_w---h3h7QANpzW4ds=.44aa8e2e-77e7-4543-9428-5a83ea308bdf@github.com>

On Thu, 5 Sep 2024 09:50:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Well, but your proof-of-concept only supports clang on linux, where you have enabled symbol hiding.

The hermetic-java-runtime branch doesn't have general symbol hiding enabled. That's why I'm wondering what the issues are with these libs except for `libjawt` with the current PR. 

(A side-note on `libjawt.a`: For static linking, we don't need `libjawt.a` and the headless or headful libs can be directly statically linked with.)

> 
> Our conclusion in the zoom talks was that we should strive for getting a static launcher build pushed into mainline before we have full and proper support for symbol hiding on all platforms.

Right, that would be a good & practical way to add the support in the mainline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746051842

From archie.cobbs at gmail.com  Thu Sep  5 19:23:59 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 5 Sep 2024 14:23:59 -0500
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>

Apologies in advance if I'm misunderstanding anything...

On Thu, Sep 5, 2024 at 2:05?PM Viktor Klang <viktor.klang at oracle.com>
wrote:

>  Thread state polling aside, for as long as Condition::await() is allowed
> to spuriously wake, FIFO just cannot be "guaranteed".


What about this statement in the Javadoc for ReentrantLock.newCondition():

The ordering of lock reacquisition for threads returning from waiting
> methods is the same as for threads initially acquiring the lock, which is
> in the default case not specified, but for *fair* locks favors those
> threads that have been waiting the longest.


So what you're saying is that a spurious wakeup on a Condition is not the
same thing as a spurious signal() on a Condition; if it were, then the
above statement would apply and FIFO ordering would be preserved.

Of course, a spurious wakeup would not find the condition being waited on
satisfied unless there was a big coincidence. So an ordering violation that
actually mattered should be exceedingly rare.

Anyway, this does seem to be a glitch in how things are supposed to work.
That is: there can be no guaranteed ordering for Condition waiters when
there can be spurious wakeups.

Maybe this corner case should be documented. Or better yet, fix the bug by
requiring Condition to "filter out" spurious wakeups if preserving FIFO
ordering (it should be possible).

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/cced8722/attachment.htm>

From viktor.klang at oracle.com  Thu Sep  5 19:52:51 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 5 Sep 2024 19:52:51 +0000
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
Message-ID: <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>

Archie,

I should've been more specific?Condition-as-implemented-by-ReentrantLock (in fair mode) provides stronger (for some definition of stronger) semantics that the Condition interface specifies.

Since it's related, I've recently integrated a hardening of AQS and AQLS reacquisition logic in await().

Given what you presented earlier about the detection of "producer parked" it's likely that the conclusion is that ABQ works as expected.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Archie Cobbs <archie.cobbs at gmail.com>
Sent: Thursday, 5 September 2024 21:23
To: Viktor Klang <viktor.klang at oracle.com>
Cc: ??? <miiiinju00 at gmail.com>; Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Apologies in advance if I'm misunderstanding anything...

On Thu, Sep 5, 2024 at 2:05?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
 Thread state polling aside, for as long as Condition::await() is allowed to spuriously wake, FIFO just cannot be "guaranteed".

What about this statement in the Javadoc for ReentrantLock.newCondition():

The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.

So what you're saying is that a spurious wakeup on a Condition is not the same thing as a spurious signal() on a Condition; if it were, then the above statement would apply and FIFO ordering would be preserved.

Of course, a spurious wakeup would not find the condition being waited on satisfied unless there was a big coincidence. So an ordering violation that actually mattered should be exceedingly rare.

Anyway, this does seem to be a glitch in how things are supposed to work. That is: there can be no guaranteed ordering for Condition waiters when there can be spurious wakeups.

Maybe this corner case should be documented. Or better yet, fix the bug by requiring Condition to "filter out" spurious wakeups if preserving FIFO ordering (it should be possible).

-Archie

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240905/f49b70ad/attachment-0001.htm>

From jiangli at openjdk.org  Thu Sep  5 20:39:51 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 20:39:51 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <bfBaJj8ARo7c7iCF7U4ymPRfAbtKotBqj5WU_4z9490=.60be0f5a-a237-4496-905b-ef51128b3189@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <bfBaJj8ARo7c7iCF7U4ymPRfAbtKotBqj5WU_4z9490=.60be0f5a-a237-4496-905b-ef51128b3189@github.com>
Message-ID: <r7W5pQxzeIaE8GIvW_vri7SpZk2HDsBj6339ouuS5vY=.014c1ff8-d800-42f3-bfe2-7121e5e0cbc2@github.com>

On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/StaticLibs.gmk line 71:
>> 
>>> 69:   # libsspi_bridge has name conflicts with sunmscapi
>>> 70:   BROKEN_STATIC_LIBS += sspi_bridge
>>> 71:   # These libs define DllMain which conflict with Hotspot
>> 
>> I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch.
>
> DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMai
 n when compiling them as static libraries

@TheShermanTanker thanks for the details on DllMain issue. Right, we have only tested hermetic/static Java on Linux.

I agree that hiding DllMain is not the right approach. One possible solution is to put the DllMain in separate .c/.cpp files and only link with those when building the .dll. 

With the current PR, we mainly focuses on the Linux (or unix-like) port, e.g. `os::lookup_function()` is not supported in the Windows port yet. Any thoughts on if we only limit static linking these affected JDK libraries on Windows initially, and allow statically linking more libs on Linux? We can add those libs on Windows when we resolve the DllMain issue. For running some minimum jtreg testing initially, I think we would want to include `libnet` (and other libs) in the statically linked `java` binary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746129101

From jiangli at openjdk.org  Thu Sep  5 20:43:52 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 20:43:52 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
Message-ID: <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>

On Thu, 5 Sep 2024 10:03:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/StaticLibs.gmk line 118:
>> 
>>> 116:     OPTIMIZATION := HIGH, \
>>> 117:     STATIC_LAUNCHER := true, \
>>> 118:     LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \
>> 
>> I could be missing something, but I don't see where is $JAVASTATIC_LINK_LDFLAGS defined.
>> 
>> On a related notes, I think we need to include $JVM_LDFLAGS when linking the static "java". See https://bugs.openjdk.org/browse/JDK-8339522?focusedId=14702923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14702923.
>
> You are right, this is dead code. Thanks for spotting this. 
> 
> During my experimentation, I tried passing along LDFLAGS from the individual libraries as well, but it turned out not to be a good idea -- the way we have used them were to modify some special properties on a single dynamic library, which did not apply to the static library as a whole.
> 
> However, there is a risk that we in the future need to add LDFLAGS to a library that also needs to be carried over to the static launcher. If this happens, I guess we need to separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING.

+1 on "separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING"

I think we need to get the linker flags sorted out correctly in this initial PR and make sure the needed flags (most importantly the ones used in $JVM_LDFLAGS).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746133505

From jiangli at openjdk.org  Thu Sep  5 20:47:50 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 5 Sep 2024 20:47:50 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <Yc36M18CA-LzcyvnVwL7D_8CE-nPC8WtO7gMnPzQ9-U=.353a312a-64f4-41d9-ae51-dcd93a2c819c@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <Yc36M18CA-LzcyvnVwL7D_8CE-nPC8WtO7gMnPzQ9-U=.353a312a-64f4-41d9-ae51-dcd93a2c819c@github.com>
Message-ID: <UDcq933mLhYdzTGhxuxX8Wm7gDlkOrH7oXbkelCtKPQ=.85b649fd-06da-4349-874a-011a4f31f5bc@github.com>

On Thu, 5 Sep 2024 09:57:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.desktop/lib/AwtLibraries.gmk line 176:
>> 
>>> 174: 
>>> 175:   ifneq ($(ENABLE_HEADLESS_ONLY), true)
>>> 176:     # We cannot link with both awt_headless and awt_xawt at the same time
>> 
>> Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java.
>
> That would require quite some work then..! The two libraries are meant as exclusive complements to each other -- they both implement the same "entry points", but in different ways -- one with X11 support, and one without. For other reasons (outside of static launcher reasons) I'd like to see some refactoring in how this is implemented, but that is completely outside this discussion.
> 
> For the static launcher scenario, I can't even see the point of trying to include both? What would you accomplish by that? 
> 
> The entire point of having two libraries is that you want to be able to have full workstation capabilities, but then be dependent on the X11 libraries, or have limited capabilities, but skip the X11 dependency.

My initial understanding was that the libawt_headless was mostly as subset of libawt_xawt, which made it possible to statically link both the headless and headful natives. Completely agree that it's outside of the current scope.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746136942

From bpb at openjdk.org  Thu Sep  5 21:11:17 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Sep 2024 21:11:17 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks
Message-ID: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>

Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

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

Commit messages:
 - 8339574: Behavior of File.is{Directory,File,Hidden} is not documented with respect to symlinks

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

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

From kcr at openjdk.org  Thu Sep  5 21:16:58 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Sep 2024 21:16:58 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
Message-ID: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>

Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.

See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.

This PR does two things:

1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

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

Commit messages:
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Update javadoc
 - Update copyright years
 - Merge branch 'master' into 8311530-depr-jsobject
 - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
 - 8311530: Deprecate jdk.jsobject module for removal

Changes: https://git.openjdk.org/jdk/pull/20555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311530
  Stats: 27 lines in 7 files changed: 17 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555

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

From kcr at openjdk.org  Thu Sep  5 21:16:58 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Sep 2024 21:16:58 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <p97afTZnY5Z8tP60HwLAOqiTumwQgsY321virh85zbs=.b1fa1990-349d-4966-8249-e771a4fda8ba@github.com>

On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

The GHA run shows a spurious failure in macOS (a network timeout cloning the repo). I'll rerun it with no changes to my branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2332635931

From liach at openjdk.org  Thu Sep  5 21:44:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 21:44:50 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v8]
In-Reply-To: <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
Message-ID: <sTxgF0ebfSb53pAJTXet1Q_NKelwUA5cnJQ2dMj1j2I=.70d00a6f-0edc-4ee5-869c-17bae9f787de@github.com>

On Thu, 5 Sep 2024 05:07:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove benchmark

Thanks. It appears these are all use cases of the slotSize methods.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20747#pullrequestreview-2284128465

From prappo at openjdk.org  Thu Sep  5 21:53:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Sep 2024 21:53:58 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
Message-ID: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>

This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:

  - [JLS]
  - [JVMS]

Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.

[issues]: https://bugs.openjdk.org/browse/JDK-8339558
[JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
[JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

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

Commit messages:
 - Initial commit

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

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

From darcy at openjdk.org  Thu Sep  5 21:53:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Sep 2024 21:53:59 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <5ZAsYJjpuLQrxcpRMOY3h8H_IpO7tgAmczbmoIVkYts=.089531e7-6b14-4dd4-9395-ae7afc1cafbb@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

Looks fine; thanks.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2284138298

From liach at openjdk.org  Thu Sep  5 22:01:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 22:01:50 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v6]
In-Reply-To: <XGHbduMULIcz92cf3VB-hQVn9lP-ywBemwvgI45h3zo=.91b30b91-c406-4f81-8d96-eebd92f1c7d7@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <XGHbduMULIcz92cf3VB-hQVn9lP-ywBemwvgI45h3zo=.91b30b91-c406-4f81-8d96-eebd92f1c7d7@github.com>
Message-ID: <SVAvpd0ZYwP0NH4jKsDHIh5hxGScL6Vtq0WKIg0OKeA=.79468122-dd25-4f7e-a0d9-039c7eb0dd21@github.com>

On Wed, 4 Sep 2024 00:36:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Eliminate redundant variables
>  - buf skip

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 449:

> 447:                         }
> 448:                         int byteLengthFinal = byteLength;
> 449:                         pool.patchU2(pool.size() - i - 2, byteLengthFinal);

This change is causing conflict with your utf8 writing enhancement. Can you revert this change and squash commits, or merge latest master to fix this conflict?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1746202190

From jjg at openjdk.org  Thu Sep  5 22:04:49 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 5 Sep 2024 22:04:49 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2284150971

From liach at openjdk.org  Thu Sep  5 22:10:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 22:10:48 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
Message-ID: <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>

On Thu, 5 Sep 2024 22:01:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`

For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch does not wrap `instanceof` in a code tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2332713929

From prappo at openjdk.org  Thu Sep  5 22:17:48 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Sep 2024 22:17:48 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
 <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>
Message-ID: <-j2KsqOYz6TMGTQ1j6CS3fp7azbiNXcXIaFrvnwX32c=.5cd321a0-d4f0-4187-b635-ab10be5782e0@github.com>

On Thu, 5 Sep 2024 22:08:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> > possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`
> 
> 
> 
> For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch does not wrap `instanceof` in a code tag.

Typography issues are less severe than those fixed in this PR, but I can fix them too.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2332721312

From swen at openjdk.org  Thu Sep  5 22:47:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 22:47:00 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v7]
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

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

 - Merge remote-tracking branch 'origin/class_file_buf_writer_imp_202408_patch_int' into class_file_buf_writer_imp_202408_patch_int
 - Eliminate redundant variables
 - buf skip
 - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
 - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
 - revert skip
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Suggestions from @cl4es
 - ... and 3 more: https://git.openjdk.org/jdk/compare/8fb8cd85...e7f57a6f

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

Changes: https://git.openjdk.org/jdk/pull/20780/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20780&range=06
  Stats: 56 lines in 7 files changed: 32 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20780.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20780/head:pull/20780

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

From swen at openjdk.org  Thu Sep  5 22:59:58 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 22:59:58 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings off
Message-ID: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>

A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance

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

Commit messages:
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - optimize for CompactStrings is off

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

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

From duke at openjdk.org  Thu Sep  5 22:59:59 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 5 Sep 2024 22:59:59 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off
In-Reply-To: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
Message-ID: <sRB0bXaaDi6_k9pu0x1ALQxzEvC49O9f_Rc_EcrxIiM=.06473a51-56d0-4122-884d-f432066ccfd8@github.com>

On Tue, 27 Aug 2024 05:08:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance

The?`JLA?.stringInitCoder()?!=?0` check?should?probably be?the?first?thing in?this?method, so?that **C2**?can?reliably turn?it?into a?`nop`?when compact?strings are?off:

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1204:

> 1202:          * Returns null if no such parameter exists or CompactStrings is off.
> 1203:          */
> 1204:         private static MethodTypeDesc coderArgsIfMaybeUTF16(MethodType concatArgs) {

Suggestion:

        private static MethodTypeDesc coderArgsIfMaybeUTF16(MethodType concatArgs) {
            if (JLA.stringInitCoder() != 0) {
                return null;
            }

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1214:

> 1212:             }
> 1213: 
> 1214:             if (maybeUTF16Count == 0 || JLA.stringInitCoder() != 0) {

Suggestion:

            if (maybeUTF16Count == 0) {

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

PR Review: https://git.openjdk.org/jdk/pull/20722#pullrequestreview-2262445378
PR Review Comment: https://git.openjdk.org/jdk/pull/20722#discussion_r1732390180
PR Review Comment: https://git.openjdk.org/jdk/pull/20722#discussion_r1732390401

From liach at openjdk.org  Thu Sep  5 23:06:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 23:06:52 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v7]
In-Reply-To: <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
Message-ID: <xqe8ADIpFRXaPz1c_SepGrtHCLLIQ71EGJN79Afk5bc=.af832521-3e48-477a-800b-40c789845dd0@github.com>

On Thu, 5 Sep 2024 22:47:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge remote-tracking branch 'origin/class_file_buf_writer_imp_202408_patch_int' into class_file_buf_writer_imp_202408_patch_int
>  - Eliminate redundant variables
>  - buf skip
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - revert skip
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Suggestions from @cl4es
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/8fb8cd85...e7f57a6f

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20780#pullrequestreview-2284271490

From liach at openjdk.org  Thu Sep  5 23:07:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 23:07:20 GMT
Subject: RFR: 8339519: Remove size field from instructions
Message-ID: <d0rdAh9IYv_LBLd8W9Z58yzwPGyS8NQg2mY4fU_TXOM=.8e5513ac-6f27-4eaa-a92a-8e391df0be6c@github.com>

`AbstractInstruction` has a redundant `size` field unnecessary for the majority of instructions. We should add this field to the 2 switch instructions that need it only.

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

Commit messages:
 - 8339519: Remove size field from instructions

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

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

From swen at openjdk.org  Thu Sep  5 23:22:01 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 23:22:01 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v6]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <ohay97S37skGwx92aekBvqjjHJTxgSQQqvieR7nwHKw=.8d570514-4b47-4f28-8b7e-924bc4e36a01@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

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

 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - reuseThreshold -> cacheThreshold
 - Revert "optimize for CompactStrings is off"
   
   This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.
 - optimize for CompactStrings is off
 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - add control flag `reuseThreshold`
 - Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
   
   This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.
 - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
 - revert code style
 - from suggest
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8fb8cd85...5c12e337

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

Changes: https://git.openjdk.org/jdk/pull/20675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=05
  Stats: 130 lines in 3 files changed: 81 ins; 2 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

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

From liach at openjdk.org  Thu Sep  5 23:22:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 23:22:51 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off
In-Reply-To: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
Message-ID: <h6q6nfXJb4z-SznK3lhtScUH-t0TiPoMJi_z3Si1qpk=.64a94875-c77a-4828-8547-581f8d0b5b8c@github.com>

On Tue, 27 Aug 2024 05:08:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance

src/java.base/share/classes/java/lang/System.java line 2641:

> 2639:             }
> 2640: 
> 2641:             public byte stringInitCoder() {

Why do we expose this as a coder instead of other ways, such as a `boolean hasCompactStrings()`? Are we going to use this coder elsewhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20722#discussion_r1746298499

From swen at openjdk.org  Thu Sep  5 23:42:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 5 Sep 2024 23:42:50 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off
In-Reply-To: <h6q6nfXJb4z-SznK3lhtScUH-t0TiPoMJi_z3Si1qpk=.64a94875-c77a-4828-8547-581f8d0b5b8c@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
 <h6q6nfXJb4z-SznK3lhtScUH-t0TiPoMJi_z3Si1qpk=.64a94875-c77a-4828-8547-581f8d0b5b8c@github.com>
Message-ID: <4Nylm_mntjVT-yA_y0sOOIrcBEqEo7L6A-V7f6ZSMHU=.0b04c961-12f0-420e-90eb-3cde0c6f1c0c@github.com>

On Thu, 5 Sep 2024 23:20:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance
>
> src/java.base/share/classes/java/lang/System.java line 2641:
> 
>> 2639:             }
>> 2640: 
>> 2641:             public byte stringInitCoder() {
> 
> Why do we expose this as a coder instead of other ways, such as a `boolean hasCompactStrings()`? Are we going to use this coder elsewhere?

Because there is already another method `stringConcatInitialCoder`, stringInitCoder is exposed to keep it consistent with the current code style as much as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20722#discussion_r1746316064

From liach at openjdk.org  Thu Sep  5 23:45:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 23:45:55 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v6]
In-Reply-To: <ohay97S37skGwx92aekBvqjjHJTxgSQQqvieR7nwHKw=.8d570514-4b47-4f28-8b7e-924bc4e36a01@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ohay97S37skGwx92aekBvqjjHJTxgSQQqvieR7nwHKw=.8d570514-4b47-4f28-8b7e-924bc4e36a01@github.com>
Message-ID: <pzr5Ig5ABsIAPi-BEgkIufj6k_IdwyVk9yRFhxBdSEg=.28910001-a14b-4e7d-87bf-20c2aeea4de9@github.com>

On Thu, 5 Sep 2024 23:22:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - reuseThreshold -> cacheThreshold
>  - Revert "optimize for CompactStrings is off"
>    
>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.
>  - optimize for CompactStrings is off
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - add control flag `reuseThreshold`
>  - Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
>    
>    This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.
>  - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
>  - revert code style
>  - from suggest
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/8fb8cd85...5c12e337

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1288:

> 1286:                             if (staticConcat) {
> 1287:                                 clb.withSuperclass(CD_Object)
> 1288:                                    .withFlags(ACC_FINAL | ACC_SUPER | ACC_SYNTHETIC);

According to #19517, project lilliput wants utility classes to be declared `abstract` instead of `final` so their pointers won't be encodable in object headers

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1495:

> 1493:                      */
> 1494:                     if (staticConcat) {
> 1495:                         cb.ldc(coder);

`coder` can only be 0 or 1, so using `loadConstant` to generate `iconst_0` or `iconst_1` is better. Other `ldc` with number can be potentially replaced by `loadConstant` to generate optimized instructions too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1746314754
PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1746315741

From liach at openjdk.org  Thu Sep  5 23:46:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 23:46:49 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off
In-Reply-To: <4Nylm_mntjVT-yA_y0sOOIrcBEqEo7L6A-V7f6ZSMHU=.0b04c961-12f0-420e-90eb-3cde0c6f1c0c@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
 <h6q6nfXJb4z-SznK3lhtScUH-t0TiPoMJi_z3Si1qpk=.64a94875-c77a-4828-8547-581f8d0b5b8c@github.com>
 <4Nylm_mntjVT-yA_y0sOOIrcBEqEo7L6A-V7f6ZSMHU=.0b04c961-12f0-420e-90eb-3cde0c6f1c0c@github.com>
Message-ID: <k7FceTQz80jkqp6ah2NdVsYo-c2TxhlSm47fjrARrac=.5d194abd-1df8-450b-b118-9f342123e5aa@github.com>

On Thu, 5 Sep 2024 23:39:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2641:
>> 
>>> 2639:             }
>>> 2640: 
>>> 2641:             public byte stringInitCoder() {
>> 
>> Why do we expose this as a coder instead of other ways, such as a `boolean hasCompactStrings()`? Are we going to use this coder elsewhere?
>
> Because there is already another method `stringConcatInitialCoder`, stringInitCoder is exposed to keep it consistent with the current code style as much as possible.

I see now that you've added it in #20675. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20722#discussion_r1746318029

From liach at openjdk.org  Thu Sep  5 23:46:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 23:46:50 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off
In-Reply-To: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
Message-ID: <1HsNkaTkB3QRpgnA5UYtW89KJ1q9iYwntktqauIFfUY=.9f0e2919-7c15-42d1-bdb5-80b111809a3d@github.com>

On Tue, 27 Aug 2024 05:08:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455:

> 453:     Object stringConcat1(String[] constants);
> 454: 
> 455:     byte stringInitCoder();

Can you add javadoc comment about on this API, like the javadoc for other JLA methods?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20722#discussion_r1746318345

From bpb at openjdk.org  Fri Sep  6 00:07:49 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Sep 2024 00:07:49 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <y4MKh-aYJh-GueHxTz6qG54756lc5numwWfnnB2KFB0=.b2560ae7-db83-4b47-af31-fe2c24b4cab9@github.com>

On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

If the `File` is a symbolic link, it looks after all that for most methods, the final target of link is used. The methods where the link itself is used are `isHidden()` (Unix only), and `delete()`. Given this, perhaps a better approach would be to add a statement in the class specification that links are followed unless a method specification states the contrary?

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

PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2332924513

From swen at openjdk.org  Fri Sep  6 00:21:07 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 00:21:07 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off [v2]
In-Reply-To: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
Message-ID: <Nvra7DQlboy3kBvDEPizVWWhNBEdEud9WuZ4bP3Oesc=.e2d4e6bb-a494-4760-bd90-37ca23b2a7ea@github.com>

> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance

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

  add java doc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20722/files
  - new: https://git.openjdk.org/jdk/pull/20722/files/067bb0dc..32979c13

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

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

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

From swen at openjdk.org  Fri Sep  6 00:48:01 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 00:48:01 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v6]
In-Reply-To: <pzr5Ig5ABsIAPi-BEgkIufj6k_IdwyVk9yRFhxBdSEg=.28910001-a14b-4e7d-87bf-20c2aeea4de9@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ohay97S37skGwx92aekBvqjjHJTxgSQQqvieR7nwHKw=.8d570514-4b47-4f28-8b7e-924bc4e36a01@github.com>
 <pzr5Ig5ABsIAPi-BEgkIufj6k_IdwyVk9yRFhxBdSEg=.28910001-a14b-4e7d-87bf-20c2aeea4de9@github.com>
Message-ID: <biRayeHCJG9HCSaRE4iJpV3f023TKuVHbovTc3X9584=.c1404c76-42cf-47bf-b5ed-253588183fc1@github.com>

On Thu, 5 Sep 2024 23:37:30 GMT, Chen Liang <liach 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 12 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>>  - reuseThreshold -> cacheThreshold
>>  - Revert "optimize for CompactStrings is off"
>>    
>>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.
>>  - optimize for CompactStrings is off
>>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>>  - add control flag `reuseThreshold`
>>  - Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
>>    
>>    This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.
>>  - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
>>  - revert code style
>>  - from suggest
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/8fb8cd85...5c12e337
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1288:
> 
>> 1286:                             if (staticConcat) {
>> 1287:                                 clb.withSuperclass(CD_Object)
>> 1288:                                    .withFlags(ACC_FINAL | ACC_SUPER | ACC_SYNTHETIC);
> 
> According to #19517, project lilliput wants utility classes to be declared `abstract` instead of `final` so their pointers won't be encodable in object headers

Do I need to declare it as ACC_INTERFACE? Many utility classes do this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1746349350

From liach at openjdk.org  Fri Sep  6 01:00:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 01:00:54 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off [v2]
In-Reply-To: <Nvra7DQlboy3kBvDEPizVWWhNBEdEud9WuZ4bP3Oesc=.e2d4e6bb-a494-4760-bd90-37ca23b2a7ea@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
 <Nvra7DQlboy3kBvDEPizVWWhNBEdEud9WuZ4bP3Oesc=.e2d4e6bb-a494-4760-bd90-37ca23b2a7ea@github.com>
Message-ID: <XLhY3UZsM4DKPNz1A4L8BXy3zW5MBRsWU1nS_YLZJdg=.39b153c0-17c2-4aa0-92fb-dce8186720e7@github.com>

On Fri, 6 Sep 2024 00:21:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add java doc

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20722#pullrequestreview-2284384596

From swen at openjdk.org  Fri Sep  6 01:01:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 01:01:31 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v7]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <CUYXpb-XrRGQ2cRUza6wpCf7OFMu1evVmOfhJF4-CRo=.5d3d2b0e-42d1-4df2-a6f9-4e4748f44ac6@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

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

  suggestion from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/5c12e337..9211f1ee

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

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

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

From liach at openjdk.org  Fri Sep  6 01:03:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 01:03:52 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v6]
In-Reply-To: <biRayeHCJG9HCSaRE4iJpV3f023TKuVHbovTc3X9584=.c1404c76-42cf-47bf-b5ed-253588183fc1@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ohay97S37skGwx92aekBvqjjHJTxgSQQqvieR7nwHKw=.8d570514-4b47-4f28-8b7e-924bc4e36a01@github.com>
 <pzr5Ig5ABsIAPi-BEgkIufj6k_IdwyVk9yRFhxBdSEg=.28910001-a14b-4e7d-87bf-20c2aeea4de9@github.com>
 <biRayeHCJG9HCSaRE4iJpV3f023TKuVHbovTc3X9584=.c1404c76-42cf-47bf-b5ed-253588183fc1@github.com>
Message-ID: <iAp03WoHNkumYntB9WSsx6j03W33P5VN6-Iv7TBfis8=.5ce1c09b-cffe-4930-8be1-cf99e58a539f@github.com>

On Fri, 6 Sep 2024 00:45:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1288:
>> 
>>> 1286:                             if (staticConcat) {
>>> 1287:                                 clb.withSuperclass(CD_Object)
>>> 1288:                                    .withFlags(ACC_FINAL | ACC_SUPER | ACC_SYNTHETIC);
>> 
>> According to #19517, project lilliput wants utility classes to be declared `abstract` instead of `final` so their pointers won't be encodable in object headers
>
> Do I need to declare it as ACC_INTERFACE? Many utility classes do this.

interface has extra restrictions that can fail class validation, such as fields must be public static final. So I recommend just using abstract class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1746356802

From swen at openjdk.org  Fri Sep  6 01:12:27 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 01:12:27 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v8]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <CdqfnJS6-jYi9lTXzo-s-xG_1eIAztgbn00P5HaeOPc=.c10b77c6-342a-48be-a35e-38369a0ab3e7@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

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

  ACC_ABSTRACT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/9211f1ee..051cc5ed

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

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

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

From swen at openjdk.org  Fri Sep  6 01:12:27 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 01:12:27 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v6]
In-Reply-To: <iAp03WoHNkumYntB9WSsx6j03W33P5VN6-Iv7TBfis8=.5ce1c09b-cffe-4930-8be1-cf99e58a539f@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ohay97S37skGwx92aekBvqjjHJTxgSQQqvieR7nwHKw=.8d570514-4b47-4f28-8b7e-924bc4e36a01@github.com>
 <pzr5Ig5ABsIAPi-BEgkIufj6k_IdwyVk9yRFhxBdSEg=.28910001-a14b-4e7d-87bf-20c2aeea4de9@github.com>
 <biRayeHCJG9HCSaRE4iJpV3f023TKuVHbovTc3X9584=.c1404c76-42cf-47bf-b5ed-253588183fc1@github.com>
 <iAp03WoHNkumYntB9WSsx6j03W33P5VN6-Iv7TBfis8=.5ce1c09b-cffe-4930-8be1-cf99e58a539f@github.com>
Message-ID: <fozxtcIFx6iRn3tdON9uGJ0rs1lxicFFlNVN4_TgzQQ=.40413e10-39ea-4d40-9f15-726e616d5fc5@github.com>

On Fri, 6 Sep 2024 01:01:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Do I need to declare it as ACC_INTERFACE? Many utility classes do this.
>
> interface has extra restrictions that can fail class validation, such as fields must be public static final. So I recommend just using abstract class.

Thanks, I learned something new!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1746360230

From rriggs at openjdk.org  Fri Sep  6 01:54:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 6 Sep 2024 01:54:55 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com>

On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

Looks good. I'll review the CSR when its ready.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20555#pullrequestreview-2284421844

From miiiinju00 at gmail.com  Fri Sep  6 02:43:49 2024
From: miiiinju00 at gmail.com (=?UTF-8?B?6rmA66+87KO8?=)
Date: Fri, 6 Sep 2024 11:43:49 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>

*Hi Archie,*

Thanks to your valuable suggestions, I was able to come up with a much more
appropriate test, and I?ve learned a great deal in the process. I truly
appreciate your insights! While this approach is clearly a significant
improvement over the previous one, I still feel there might be concerns
about the atomicity between notFull.await() and the signaling from outside,
but I can?t deny that this new approach provides much better guarantees.
Your feedback has been incredibly helpful, and I?m very grateful for your
time and effort. Thank you again!





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

*Hi Viktor,*

Thank you for sharing your thoughts, which have given me much to consider.
I have a follow-up question regarding the improvements in AQS that you
mentioned. Specifically, I?d like to clarify whether these improvements
ensure that, in the fair mode of ReentrantLock, threads waiting on a
Condition are placed back in the queue without acquiring the lock, or if
the signaling thread can now immediately acquire the lock after being
signaled.

Initially, my concern was that a thread receiving a signal might still face
starvation if another thread calls put() and acquires the lock before the
signaled thread can do so. Here's an example scenario:

   1. The queue is full, and T2 is executing put() and is waiting in
   Condition.await().
   2. T1 calls queue.take(), removes an item from the queue, and is about
   to send a signal()
   3. T3 is about to call put() and is just before lock.lockInterruptibly().
   4. T1 decreases the count and sends a signal(), indicating that space is
   available in the queue.
   5. T3 acquires the lock via lock.lockInterruptibly(), successfully
   enqueues an item because the count condition is satisfied, and releases the
   lock.
   6. T2 receives the signal and wakes up, but since T3 already enqueued an
   item, the count has increased, and T2 must wait again in await().

It seems to me that this scenario could occur regardless of whether
ReentrantLock is in fair mode or not. Has the improvement in AQS addressed
this type of contention scenario to prevent such starvation issues, or is
this still a possible outcome?
------------------------------

Your insights into "unbounded unfairness" have also provided me with a lot
of food for thought, and I?m grateful for the opportunity to reflect on
these issues.

In your view, would the thread contention scenario I?ve described fall
under the category of unbounded unfairness, or would it be considered an
acceptable level of contention?


Once again, thank you for all the knowledge and understanding I've gained
through your feedback. I'm truly grateful for your time and expertise.



Best regards,
Kim Minju



2024? 9? 6? (?) ?? 4:52, Viktor Klang <viktor.klang at oracle.com>?? ??:

> Archie,
>
> I should've been more specific?Condition-as-implemented-by-ReentrantLock
> (in fair mode) provides stronger (for some definition of stronger)
> semantics that the Condition interface specifies.
>
> Since it's related, I've recently integrated a hardening of AQS and AQLS
> reacquisition logic in await().
>
> Given what you presented earlier about the detection of "producer parked"
> it's likely that the conclusion is that ABQ works as expected.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Archie Cobbs <archie.cobbs at gmail.com>
> *Sent:* Thursday, 5 September 2024 21:23
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* ??? <miiiinju00 at gmail.com>; Daniel FUCHS <daniel.fuchs at oracle.com>;
> core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation
> in BlockingQueue under high contention and suggestion for fair mode in
> ArrayBlockingQueue and LinkedBlockingQueue
>
> Apologies in advance if I'm misunderstanding anything...
>
> On Thu, Sep 5, 2024 at 2:05?PM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>  Thread state polling aside, for as long as Condition::await() is allowed
> to spuriously wake, FIFO just cannot be "guaranteed".
>
>
> What about this statement in the Javadoc for ReentrantLock.newCondition():
>
> The ordering of lock reacquisition for threads returning from waiting
> methods is the same as for threads initially acquiring the lock, which is
> in the default case not specified, but for *fair* locks favors those
> threads that have been waiting the longest.
>
>
> So what you're saying is that a spurious wakeup on a Condition is not the
> same thing as a spurious signal() on a Condition; if it were, then the
> above statement would apply and FIFO ordering would be preserved.
>
> Of course, a spurious wakeup would not find the condition being waited on
> satisfied unless there was a big coincidence. So an ordering violation that
> actually mattered should be exceedingly rare.
>
> Anyway, this does seem to be a glitch in how things are supposed to work.
> That is: there can be no guaranteed ordering for Condition waiters when
> there can be spurious wakeups.
>
> Maybe this corner case should be documented. Or better yet, fix the bug by
> requiring Condition to "filter out" spurious wakeups if preserving FIFO
> ordering (it should be possible).
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240906/2575eea5/attachment-0001.htm>

From darcy at openjdk.org  Fri Sep  6 02:44:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 6 Sep 2024 02:44:53 GMT
Subject: RFR: 8336043: Add quality of implementation discussion to
 Object.{equals, toString, hashCode} [v5]
In-Reply-To: <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
References: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
 <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
Message-ID: <ZhG3BjDHx1VfuoNa1kJo4DVIuhgl8yywFWm_Ri2cgpU=.39494397-04b0-4870-8107-449c605ed0dc@github.com>

On Wed, 7 Aug 2024 00:02:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First pass at adding some quality of implementation discussions around the overridable methods of Object.
>
> Joe Darcy 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:
> 
>  - Fix typo found in code review.
>  - Merge branch 'master' into JDK-8336043
>  - Merge branch 'master' into JDK-8336043
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8336043
>  - Appease jcheck.
>  - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2333077590

From alanb at openjdk.org  Fri Sep  6 05:39:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 05:39:55 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <VfAMbg1CKLOeWRZDWJE71tVL1xpX2oA0TLa4O7fufTo=.5276aab5-c12f-44b0-b55a-594d808c5e34@github.com>

On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

The changes to make jdk.jsobject an upgradeable module looks right.

I was initially surprised by the wording "will be delivered with JavaFX" but after playing with a few alternatives I concluded that what we have is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20555#pullrequestreview-2284861631

From jbhateja at openjdk.org  Fri Sep  6 06:30:55 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Sep 2024 06:30:55 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v5]
In-Reply-To: <QX4ZEYwJYbG8EE3XnceLhmKEJS1hbq3c8ULpVyEoWDY=.62ec2239-e548-4335-8d85-235afa742dd4@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <4kI0NYrxxgGisMvfwUz0tjHy9RoNGA99qpHgS_wtrAc=.36012d46-f899-4021-aef5-8be2322e29c9@github.com>
 <TQRt9w38cIX-gRkjVANWp0aZU5mNwcU95R09ISuTo7c=.4de988d2-bd8b-43fe-9b0c-15821f82d5e0@github.com>
 <7huBzF7ygKcr1ADKYTizGsyEBNb6dWYaU3g9_StUGB4=.89495de4-e6b5-47d6-9756-41471d366211@github.com>
 <QX4ZEYwJYbG8EE3XnceLhmKEJS1hbq3c8ULpVyEoWDY=.62ec2239-e548-4335-8d85-235afa742dd4@github.com>
Message-ID: <I5pRzWK4rOJLKhFnc_I7h0EQaPEXMSTSroDFf8lPrbA=.5a36b25d-311c-414b-95c0-609e5768eec4@github.com>

On Thu, 5 Sep 2024 14:31:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.hpp line 634:
>> 
>>> 632:   virtual int Opcode() const;
>>> 633: };
>>> 634: 
>> 
>> This could also be a separate PR. Or are they somehow inseparable from the "saturation" changes?
>
> What is not applicable? Do you actually need this node for the saturating operations?

It was in context of scalar IRs, as mentioned we plan to support unsigned scalar operation and its idealizations in follow up patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1746573566

From sundar at openjdk.org  Fri Sep  6 06:31:02 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 6 Sep 2024 06:31:02 GMT
Subject: RFR: 8337422: spelling error in jlink documentation
Message-ID: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>

fixed spelling to be consistent with the rest of the man page.

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

Commit messages:
 - 8337422: spelling error in jlink documentation

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

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

From jbhateja at openjdk.org  Fri Sep  6 06:43:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Sep 2024 06:43:31 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v8]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <nOA8eBHYej8JEaxzqPMjf5Xs6D5xG17gpYkM6cc-G7w=.ccd0421c-7814-449d-a4d5-4176d1148659@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/7164783e..195390fe

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

  Stats: 24 lines in 2 files changed: 0 ins; 1 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From jbhateja at openjdk.org  Fri Sep  6 06:43:32 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Sep 2024 06:43:32 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v7]
In-Reply-To: <kdiE57Wre-w-95zW4cgbsLEfYhdKWt-Fpfk8WOWDxbE=.456c5a1b-9077-40f4-9e10-01c9fcf5cdf4@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>
 <kdiE57Wre-w-95zW4cgbsLEfYhdKWt-Fpfk8WOWDxbE=.456c5a1b-9077-40f4-9e10-01c9fcf5cdf4@github.com>
Message-ID: <sukwAqcHLqQxTht04JBypenXM-qHztU2cX0MU1I5FAM=.85b57291-c675-44d3-8124-8d716872d280@github.com>

On Thu, 5 Sep 2024 14:33:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some cleanups.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathUtils.java line 78:
> 
>> 76:      * @since 24
>> 77:      */
>> 78:     public static long addSaturating(long a, long b) {
> 
> Are these public methods any Java dev could use? If so: do we have tests for them?

Made them package private. These routines are exercised by newly added jtreg tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1746584232

From asotona at openjdk.org  Fri Sep  6 06:57:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 06:57:50 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
 [v2]
In-Reply-To: <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>
Message-ID: <OalZzc-icLz-LuWdPVux4stBSHtsHhlZuz7CIyc3kmk=.22783ac1-a848-49d4-97ad-da3728cf5bf3@github.com>

On Thu, 5 Sep 2024 15:39:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
>> 
>> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
>> 
>> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
>> 
>> Pinging @wenshao and @cl4es for review.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid repeated field usage, eliminate bound checks

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20863#pullrequestreview-2285084123

From mbaesken at openjdk.org  Fri Sep  6 07:05:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Sep 2024 07:05:22 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information [v3]
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

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

  check for ENOMEM

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20839/files
  - new: https://git.openjdk.org/jdk/pull/20839/files/f344502d..afc423ad

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

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

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

From asotona at openjdk.org  Fri Sep  6 07:43:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 07:43:52 GMT
Subject: RFR: 8339519: Remove size field from instructions
In-Reply-To: <d0rdAh9IYv_LBLd8W9Z58yzwPGyS8NQg2mY4fU_TXOM=.8e5513ac-6f27-4eaa-a92a-8e391df0be6c@github.com>
References: <d0rdAh9IYv_LBLd8W9Z58yzwPGyS8NQg2mY4fU_TXOM=.8e5513ac-6f27-4eaa-a92a-8e391df0be6c@github.com>
Message-ID: <A_To0wG9et5dKRVia6YJ8XZLeFEEaczMidNC8_MbKm8=.f0396a24-cb25-4c17-a0a1-eaa846094c46@github.com>

On Thu, 5 Sep 2024 23:02:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AbstractInstruction` has a redundant `size` field unnecessary for the majority of instructions. We should add this field to the 2 switch instructions that need it only.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20880#pullrequestreview-2285235940

From redestad at openjdk.org  Fri Sep  6 07:45:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 07:45:21 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy
Message-ID: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>

Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.

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

Commit messages:
 - Use invokeBasic to construct StringConcat instances in StringConcatFactory

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

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

From asotona at openjdk.org  Fri Sep  6 07:46:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 07:46:56 GMT
Subject: Integrated: 8339368: Switch targets are not inflated in CodeModel if
 no StackMap
In-Reply-To: <H1d-KYsWJtng8JttZ8PQMVhZ1iIZ5usGVN5rKBRw6-M=.479358c9-0a3e-44aa-af7c-bb53cf2e810d@github.com>
References: <H1d-KYsWJtng8JttZ8PQMVhZ1iIZ5usGVN5rKBRw6-M=.479358c9-0a3e-44aa-af7c-bb53cf2e810d@github.com>
Message-ID: <0FaOgBiaeaziwyZQcvmhN05bly8yJE95puG8KC6ebpE=.4aec736c-78c2-4e88-b1af-50c63c1fa1c3@github.com>

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

> ClassFile API use an alternate labels inflation method for class versions < 50 (where StackMapTable attribute is optional).
> The alternate method missed label inflation of lookup switch and table switch instructions.
> This patch fixes the label inflation method for for class versions < 50 and adds relevant test.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: a35fd386
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a35fd3861044bdb8ddae378cb666b3d2e549a8c8
Stats:     61 lines in 2 files changed: 45 ins; 12 del; 4 mod

8339368: Switch targets are not inflated in CodeModel if no StackMap

Reviewed-by: liach

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

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

From alanb at openjdk.org  Fri Sep  6 07:50:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 07:50:49 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <3mfTQKn_SMM1TM5L85l7MVVD8YM0ct6Uc5_d_prFRR8=.0421a061-8e96-40d5-8d8b-f5f699873f98@github.com>

On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

I think the scope of this is broader as it applies to FIS/FOS/RAF constructors and all File ops.  In the java.nio.file package description there is a paragraph on how file operations behave with symbol links and maybe we could link to that from the class descriptions. The main thing is that sym links should be transparent with the exception of a few operations (delete and rename/move).

The scenario of a sym link to a "hidden file" or a "hidden" sym link to something else might need a bit more thought before putting anything into normative text. It may be that we end up with something in an implNote on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2333455756

From alanb at openjdk.org  Fri Sep  6 07:57:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 07:57:50 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information [v3]
In-Reply-To: <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
Message-ID: <4sR4pcjJBvGTA9OaWcgViKgZBZrOQD1gAgh3nuGqYOk=.fe34cb21-9dd9-4957-b6ca-8cae7e920c21@github.com>

On Fri, 6 Sep 2024 07:05:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for ENOMEM

src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c line 128:

> 126:     if (errsysctl < 0) {
> 127:         JNU_ThrowByNameWithMessageAndLastError(env,
> 128:             "java/lang/RuntimeException", "sysctl failed to get info about all processes");

sysctl(3) documents the return as 0 or -1.  So maybe better if the while condition checks errsysctl == -1 and the if condition checks  errsysctl != 0. Otherwise I think this looks good and will be interesting to see if you have other sightings due to other errors.

I guess we should change the JBS/PR title to make it clearer that this issue is now about handling ENOMEM when the number of processes increases. We'll also need to create another issue for the RuntimeException throwing as that will need updates to the ProcessHandle to specify possible error/exceptions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20839#discussion_r1746669190

From redestad at openjdk.org  Fri Sep  6 08:02:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 08:02:50 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy
In-Reply-To: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
Message-ID: <dvlLwRCDR71PHHasZXIEAvurrf-J5tuDkGcjng0xr8g=.605a0af8-6be0-4d0c-ad43-04a897b94340@github.com>

On Fri, 6 Sep 2024 07:39:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.

In the Strings stress test generated by https://cl4es.github.io/snippets/StringGen.java number of generated classes drops from 6298 to 5522.  

No statistically significant change on `StringConcatStartup`, but instrumenting bytecode executed shows the disappearance of various `invoke_MT` calls.

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

PR Comment: https://git.openjdk.org/jdk/pull/20884#issuecomment-2333475480

From mbaesken at openjdk.org  Fri Sep  6 08:17:51 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Sep 2024 08:17:51 GMT
Subject: RFR: 8339487: ProcessHandleImpl native exceptions - include
 message text and last error information [v3]
In-Reply-To: <4sR4pcjJBvGTA9OaWcgViKgZBZrOQD1gAgh3nuGqYOk=.fe34cb21-9dd9-4957-b6ca-8cae7e920c21@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
 <4sR4pcjJBvGTA9OaWcgViKgZBZrOQD1gAgh3nuGqYOk=.fe34cb21-9dd9-4957-b6ca-8cae7e920c21@github.com>
Message-ID: <byKT4JLWS2KeLMvfcZe68hAqtopXl206rXPuxVxJgY0=.e83d2f03-6ba5-4cd9-9d5e-bdf3d23c6f57@github.com>

On Fri, 6 Sep 2024 07:55:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   check for ENOMEM
>
> src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c line 128:
> 
>> 126:     if (errsysctl < 0) {
>> 127:         JNU_ThrowByNameWithMessageAndLastError(env,
>> 128:             "java/lang/RuntimeException", "sysctl failed to get info about all processes");
> 
> sysctl(3) documents the return as 0 or -1.  So maybe better if the while condition checks errsysctl == -1 and the if condition checks  errsysctl != 0. Otherwise I think this looks good and will be interesting to see if you have other sightings due to other errors.
> 
> I guess we should change the JBS/PR title to make it clearer that this issue is now about handling ENOMEM when the number of processes increases. We'll also need to create another issue for the RuntimeException throwing as that will need updates to the ProcessHandle to specify possible error/exceptions.

Hi Alan, at a lot  (but not all) of places ( ProcessHandleImpl_macosx.c , also os_bsd.cpp) we test the sysctl result for < 0; maybe there was a good reason for this ?

Regarding changing the JBS title- yes sure the old title is not really good any more .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20839#discussion_r1746693340

From prappo at openjdk.org  Fri Sep  6 08:18:50 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 08:18:50 GMT
Subject: RFR: 8337422: spelling error in jlink documentation
In-Reply-To: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
References: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
Message-ID: <kXSXjOfTpSsW0VI7HqPc6NzatNDVHTB3ROgRMyIWz6w=.22588367-8963-44c8-9757-3cd4c787197d@github.com>

On Fri, 6 Sep 2024 06:26:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> fixed spelling to be consistent with the rest of the man page.

I'm not an expert here, but I remember vividly that "dependence" might not be a misspelling/typo in the world of modules. There are semantic differences which necessitate two different words. Please double check.

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

PR Comment: https://git.openjdk.org/jdk/pull/20882#issuecomment-2333503155

From alanb at openjdk.org  Fri Sep  6 08:48:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 08:48:49 GMT
Subject: RFR: 8337422: spelling error in jlink documentation
In-Reply-To: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
References: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
Message-ID: <quNiZh02xsxihMylz1Q0-SGDiaDXpUpEbhVU_nIlF_Q=.f8a99251-f538-4a32-97e2-7624942a28eb@github.com>

On Fri, 6 Sep 2024 06:26:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> fixed spelling to be consistent with the rest of the man page.

I checked the OED and it does seem to be uncountable, which makes me wonder about other places, e.g. JLS 7.7.1.

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

PR Comment: https://git.openjdk.org/jdk/pull/20882#issuecomment-2333555917

From prappo at openjdk.org  Fri Sep  6 09:16:28 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 09:16:28 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

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

  Link to 8.1.3 instead of 8.5.1
  
  8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
  Alternatively, the link can be deleted altogether.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20879/files
  - new: https://git.openjdk.org/jdk/pull/20879/files/51ffa5ee..2c3d47aa

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

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

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

From asotona at openjdk.org  Fri Sep  6 09:27:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 09:27:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
Message-ID: <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>

On Thu, 5 Sep 2024 08:49:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
>> 
>> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
>> 
>> 
>> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
>> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
>> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
>> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
>> 
>> 
>> 
>> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
>> 
>> Tests broken by these methods are :
>> 
>> 
>> jdk/classfile/VerifierSelfTest.java
>> jdk/classfile/TestRecordComponent.java
>> jdk/classfile/TestNullHostile.java	
>> jdk/classfile/OpcodesValidationTest.java
>> jdk/classfile/ClassPrinterTest.java
>> java/lang/invoke/MethodHandlesGeneralTest.java	
>> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
>> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
>> java/lang/invoke/MethodHandleProxies/BasicTest.java
>> 
>> 
>> Full list of methods
>> 
>> 
>> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
>> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
>> 
>> // making this method null-hostile causes a BootstapMethodError during the the...
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert TestNullHostile to use JUnit Jupiter API

JDK-8317356 subject is "Test ClassFile API if it deals with nulls correctly across the whole API". 

Unfortunately this pull request blindly covers the whole API with a layer of null check, which are redundant in many cases or can be placed better to avoid double-checks, save the bytecode footprint and performance.

With such massive code addition I would also expect performance impact evaluation. 

Below are just few examples of redundant checks, I did not went through the whole code.

src/java.base/share/classes/java/lang/classfile/Annotation.java line 122:

> 120:     static Annotation of(ClassDesc annotationClass,
> 121:                          List<AnnotationElement> elements) {
> 122:         requireNonNull(elements);

Isn't this covered by the method above, where the null check is also redundant?

src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 681:

> 679:      */
> 680:     static AnnotationValue of(Object value) {
> 681:         requireNonNull(value);

Below is a null test throwing IAE.

src/java.base/share/classes/java/lang/classfile/ClassFile.java line 76:

> 74:         for (var o : options){
> 75:             requireNonNull(o);
> 76:         }

Is this really necessary? I would expect NPE from ClassFile::withOptions .

src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java line 213:

> 211:             requireNonNull(i);
> 212:         }
> 213:         requireNonNull(classToSuperClass);

Obsolete checks.

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

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20556#pullrequestreview-2285569207
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746787611
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746791566
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746784544
PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1746796891

From redestad at openjdk.org  Fri Sep  6 10:07:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 10:07:22 GMT
Subject: RFR: 8339642: Reduce overheads in InvokerBytecodeGenerator
Message-ID: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>

- A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
- `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
- Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
- Various minor optimizations helping reduce bytecode size and speed up interpreter execution

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

Commit messages:
 - Reduce overheads in InvokerBytecodeGenerator

Changes: https://git.openjdk.org/jdk/pull/20887/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339642
  Stats: 75 lines in 2 files changed: 30 ins; 32 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20887/head:pull/20887

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

From alanb at openjdk.org  Fri Sep  6 10:39:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 10:39:52 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v3]
In-Reply-To: <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
Message-ID: <7J4ET9Ol_6S8bNlaMcIruWiBAwBm6c5NGYflV3uG_Do=.972c80db-9e3b-4994-a062-65bb99f994ff@github.com>

On Fri, 6 Sep 2024 07:05:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for ENOMEM

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2285891962

From alanb at openjdk.org  Fri Sep  6 10:39:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 10:39:52 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v3]
In-Reply-To: <byKT4JLWS2KeLMvfcZe68hAqtopXl206rXPuxVxJgY0=.e83d2f03-6ba5-4cd9-9d5e-bdf3d23c6f57@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
 <4sR4pcjJBvGTA9OaWcgViKgZBZrOQD1gAgh3nuGqYOk=.fe34cb21-9dd9-4957-b6ca-8cae7e920c21@github.com>
 <byKT4JLWS2KeLMvfcZe68hAqtopXl206rXPuxVxJgY0=.e83d2f03-6ba5-4cd9-9d5e-bdf3d23c6f57@github.com>
Message-ID: <PmMXxU6fZiLosfrtGksW7nNy3FdLux3qQaNHDcVB9wE=.6b4c83d6-1a22-47aa-9289-0b1c7ec5448d@github.com>

On Fri, 6 Sep 2024 08:15:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, at a lot (but not all) of places ( ProcessHandleImpl_macosx.c , also os_bsd.cpp) we test the sysctl result for < 0; maybe there was a good reason for this ?

Okay, let's go with what you have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20839#discussion_r1746911928

From kevinw at openjdk.org  Fri Sep  6 10:51:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Sep 2024 10:51:53 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v3]
In-Reply-To: <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
 <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>
Message-ID: <I7g9FwCfnu-vHdJ8-gXJQcspYVWMN9TNS-0-NDIG5Ps=.9d168351-c58c-4dbf-8f3d-73ca9d0a1275@github.com>

On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html) and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
>> 
>> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
>> 
>> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
>> 
>> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).
>
> Alan Bateman 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:
> 
>  - Sync up from loom repo
>  - Merge
>  - Sync up from loom repo
>  - Merge
>  - Sync up from loom repo
>  - Initial commit

This all looks good to me, good to have the info and control available via JMX.
jdk.management looks like the right home.


The ObjectName String "jdk.management:type=VirtualThreadScheduler" could have a public static final definition somewhere in future, but there is no obvious home, e.g. java.lang.management.ManagementFactory is in the wrong package.  Something for the future, not for this change, as I others that don't have such a symbol.

src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java line 34:

> 32: 
> 33: /**
> 34:  * Management interface for the JDK's {@linkplain Thread##virtual-threads virtual thread}

is this "Management interface for **a**" virtual thread scheduler, as in future it may be the interface generically for virtual thread schedulers?

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20816#pullrequestreview-2285923893
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1746924898

From sgehwolf at openjdk.org  Fri Sep  6 10:51:54 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 6 Sep 2024 10:51:54 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
Message-ID: <oU5Jnl9Nn8Xc2bmjPRDu1SIG_fyBrFZ_VI7_rJZp_rI=.76e770bd-78f8-4f63-b272-62e46c4b37af@github.com>

On Fri, 30 Aug 2024 11:05:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Add Whitebox check for host cpu
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comments
>>  - 8333446: Add tests for hierarchical container support
>
> Looking through the coding it looks more or less okay to me; but if you really need to run it under user 'root'  I think we will not have so much use for this in our test environments  because we use other test users.
> Not saying that this is a very bad thing,  maybe it is just the way it is, that 'root' is needed ?

@MBaesken Any more thoughts on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2333790472

From alanb at openjdk.org  Fri Sep  6 11:11:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Sep 2024 11:11:51 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v3]
In-Reply-To: <I7g9FwCfnu-vHdJ8-gXJQcspYVWMN9TNS-0-NDIG5Ps=.9d168351-c58c-4dbf-8f3d-73ca9d0a1275@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
 <uGLpUy2rqcqdixA7N7UCEpE06h8fTKWTINb7viAvlKo=.fc2dbcad-0973-4b43-9928-a54bf655b607@github.com>
 <I7g9FwCfnu-vHdJ8-gXJQcspYVWMN9TNS-0-NDIG5Ps=.9d168351-c58c-4dbf-8f3d-73ca9d0a1275@github.com>
Message-ID: <x-QRa5aLxoEpbmcDvBIs6JT5mLyUKc9vEH4Y3dwR144=.ebdcf23d-af9b-4889-8eb2-1c42ca0d6f05@github.com>

On Fri, 6 Sep 2024 10:47:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The ObjectName String "jdk.management:type=VirtualThreadScheduler" could have a public static final definition somewhere in future, but there is no obvious home, e.g. java.lang.management.ManagementFactory is in the wrong package. Something for the future, not for this change, as I others that don't have such a symbol.

JMX pre-dates default methods, one thing to explore is if the interfaces that extend PlatformManagedObject could have getObjectName as the default method. That would avoid needing to write this method in the implementation classes.

> src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java line 34:
> 
>> 32: 
>> 33: /**
>> 34:  * Management interface for the JDK's {@linkplain Thread##virtual-threads virtual thread}
> 
> is this "Management interface for **a**" virtual thread scheduler, as in future it may be the interface generically for virtual thread schedulers?

It's singular for now, so "the" is correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/20816#issuecomment-2333818694
PR Review Comment: https://git.openjdk.org/jdk/pull/20816#discussion_r1746944191

From stuefe at openjdk.org  Fri Sep  6 11:15:00 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 6 Sep 2024 11:15:00 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v5]
In-Reply-To: <0VQJugX9IulwqoN4WWxCixyhPRhfGs-48Vm5DB0s-VU=.334232df-93b0-453a-aba7-0cf26cecf8d1@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <0VQJugX9IulwqoN4WWxCixyhPRhfGs-48Vm5DB0s-VU=.334232df-93b0-453a-aba7-0cf26cecf8d1@github.com>
Message-ID: <IoTFziezl_Gg_LkR0Si0E07aia-_pru3xzss5u4l8iI=.533aa144-ac2d-4d7a-b34c-0eaecfdf602f@github.com>

On Thu, 29 Aug 2024 12:08:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add function in Metaspace to tell you if Klass pointer is in compressible space.

I still worry about unforeseen implications of not every Klass having an nKlass. It will have some implications on some of my Lilliput work. I wish we could have done this earlier. 

But in any case, this seems to be a reasonable way forward. One remark inline, otherwise this looks mostly good to me.

src/hotspot/share/memory/metaspace.hpp line 165:

> 163:     return using_class_space() && (is_in_class_space(k) || is_in_shared_metaspace(k));
> 164:   }
> 165: 

I propose to drop this, and instead add a utility function to `CompressedKlassPointers` like this:


// Returns true if p falls into the narrow Klass encoding range
inline bool CompressedKlassPointers::is_in_encoding_range(const void* p) {
  return _base != nullptr && p >= _base && p < (_base + _range);
}

(Probably  the `_base != nullptr` could even be left out, since `_range==0` and `_base==nullptr` for -UseCompressedClassPointers)

And then use that function in `jfrTraceIdKlass.cpp`. That file needs to use `CompressedKlassPointers` anyway because it needs to encode the Klass*.

This avoids having to rely on the exact composition of the memory regions inside the encoding range. What counts is whether the Klass pointer points into the narrow Klass encoding range.

Essentially, with CDS, memory looks like this:


encoding                                                               encoding              
base                                                                   end
|-----------------------------------------------------------------------|
|----CDS---| |--------------------class space---------------------------|

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

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2285987065
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1746943501

From mbaesken at openjdk.org  Fri Sep  6 11:31:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Sep 2024 11:31:52 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v9]
In-Reply-To: <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
Message-ID: <v0YAjpbOgRSJBklY5PsDGrqeYvDEOO5wHFxnoSb0kTo=.f1c35497-8eb2-4c14-bcfa-5a11e4c96bf6@github.com>

On Wed, 4 Sep 2024 17:46:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
>> - [x] GHA
>
> Severin Gehwolf 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:
> 
>  - Adapt JDK-8339148
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>  - Add root check for SystemdMemoryAwarenessTest.java
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b773bfc6...30f32d22

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19530#pullrequestreview-2286048546

From redestad at openjdk.org  Fri Sep  6 11:40:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 11:40:48 GMT
Subject: RFR: 8339642: Reduce overheads in InvokerBytecodeGenerator
In-Reply-To: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
References: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
Message-ID: <CAqooduQ6yqzcXGnkYtdH2anRe6CSlvKx3gId4M_kJU=.0e067103-37c4-4a1f-b0ed-45ffd7a8b111@github.com>

On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
> - `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
> - Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
> - Various minor optimizations helping reduce bytecode size and speed up interpreter execution

(This is part of a series of mitigations for regressions caused by the migration to the classfile API, see https://bugs.openjdk.org/browse/JDK-8338542)

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

PR Comment: https://git.openjdk.org/jdk/pull/20887#issuecomment-2333866592

From liach at openjdk.org  Fri Sep  6 11:45:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 11:45:56 GMT
Subject: RFR: 8339576: Speed up raw bytecode processing in ClassFile API
 [v2]
In-Reply-To: <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
 <Ri0a3o47aSQmoup1RLCANlF6lQJy0Nzia_vLlDaVaXg=.0e2eca5f-c7e8-4564-a4c4-3425accbb6f4@github.com>
Message-ID: <z2MlazFrmhjlHfkwP8diNJng3XPyIG-TDpsKHPSkIw8=.fb285b67-c0f1-404a-b5da-dc3371ddbabb@github.com>

On Thu, 5 Sep 2024 15:39:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
>> 
>> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
>> 
>> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
>> 
>> Pinging @wenshao and @cl4es for review.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid repeated field usage, eliminate bound checks

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/20863#issuecomment-2333872519

From liach at openjdk.org  Fri Sep  6 11:45:57 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 11:45:57 GMT
Subject: Integrated: 8339576: Speed up raw bytecode processing in ClassFile API
In-Reply-To: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
References: <BtqnF7KgNNNo2ZFU7hIIUsvqJBdz3LX2cgDBcpKMabI=.9ced8130-4f07-498b-8058-1279a37c38ef@github.com>
Message-ID: <gPQj_czMvw5fOtjup7kbQoRgdIwnfBoWvgltZ2wZ8QQ=.7b0326cd-ff96-4390-814a-3e9af927bc24@github.com>

On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, raw bytecode access goes through multiple wrappers, include one from ClassFile API and another ByteBuffer for merged big endian value reads. We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper) for safer access.
> 
> RawBytecodeHelper is also restructured so we avoid allocating it on the heap. Large `rawNext` method is now also inlined into the smaller `next` method.
> 
> Current benchmark results show this significantly speeds up `jdk.classfile.Write` and some degree of speedup for simple lambda startup. The impact on general application workloads is minuscule, but this doesn't seem to bring any regression.
> 
> Pinging @wenshao and @cl4es for review.

This pull request has now been integrated.

Changeset: a1eebbdf
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1eebbdf8a62b641b765bf4cec5066690c11a8e5
Stats:     473 lines in 9 files changed: 198 ins; 101 del; 174 mod

8339576: Speed up raw bytecode processing in ClassFile API

Co-authored-by: Shaojin Wen <swen at openjdk.org>
Reviewed-by: asotona, redestad

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

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

From swen at openjdk.org  Fri Sep  6 11:47:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 11:47:50 GMT
Subject: RFR: 8339642: Reduce overheads in InvokerBytecodeGenerator
In-Reply-To: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
References: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
Message-ID: <qk5BERfMRVXCDbX-ZeI-CvoRlF2ZFmJEiYYgeF1pqSo=.9773ad3d-20cf-44c0-a6ad-1f3281cc5655@github.com>

On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
> - `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
> - Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
> - Various minor optimizations helping reduce bytecode size and speed up interpreter execution

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 149:

> 147:         localsMap[0] = 0; // localsMap has at least one element
> 148:         for (int i = 1, index = 0; i < localsMap.length; i++) {
> 149:             Class<?> cl = mt.parameterType(i - 1);

Can we use var?

var cl = mt.parameterType(i - 1);

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 230:

> 228:         // unique static variable name
> 229:         String name;
> 230:         List<ClassData> classData = this.classData;

var classData = this.classData;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20887#discussion_r1746918308
PR Review Comment: https://git.openjdk.org/jdk/pull/20887#discussion_r1746919127

From viktor.klang at oracle.com  Fri Sep  6 11:47:58 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 6 Sep 2024 11:47:58 +0000
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
Message-ID: <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Kim,

The recent updated to AQS reacquisition has to do with behavior if for some reason there's an exception thrown (think SOE or OOM, or something like that), so it isn't really applicable in this case.


  1.  The queue is full, and T2 is executing put() and is waiting in Condition.await().
  2.  T1 calls queue.take(), removes an item from the queue, and is about to send a signal()
  3.  T3 is about to call put() and is just before lock.lockInterruptibly().
  4.  T1 decreases the count and sends a signal(), indicating that space is available in the queue.
  5.  T3 acquires the lock via lock.lockInterruptibly(), successfully enqueues an item because the count condition is satisfied, and releases the lock.
  6.  T2 receives the signal and wakes up, but since T3 already enqueued an item, the count has increased, and T2 must wait again in await().

I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge". (tryLock() is documented to allow barging)

Let us know if you can come up with a reproducer which says otherwise. ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: ??? <miiiinju00 at gmail.com>
Sent: Friday, 6 September 2024 04:43
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Archie Cobbs <archie.cobbs at gmail.com>; Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue


Hi Archie,

Thanks to your valuable suggestions, I was able to come up with a much more appropriate test, and I?ve learned a great deal in the process. I truly appreciate your insights! While this approach is clearly a significant improvement over the previous one, I still feel there might be concerns about the atomicity between notFull.await() and the signaling from outside, but I can?t deny that this new approach provides much better guarantees. Your feedback has been incredibly helpful, and I?m very grateful for your time and effort. Thank you again!





________________________________

Hi Viktor,

Thank you for sharing your thoughts, which have given me much to consider. I have a follow-up question regarding the improvements in AQS that you mentioned. Specifically, I?d like to clarify whether these improvements ensure that, in the fair mode of ReentrantLock, threads waiting on a Condition are placed back in the queue without acquiring the lock, or if the signaling thread can now immediately acquire the lock after being signaled.

Initially, my concern was that a thread receiving a signal might still face starvation if another thread calls put() and acquires the lock before the signaled thread can do so. Here's an example scenario:

  1.  The queue is full, and T2 is executing put() and is waiting in Condition.await().
  2.  T1 calls queue.take(), removes an item from the queue, and is about to send a signal()
  3.  T3 is about to call put() and is just before lock.lockInterruptibly().
  4.  T1 decreases the count and sends a signal(), indicating that space is available in the queue.
  5.  T3 acquires the lock via lock.lockInterruptibly(), successfully enqueues an item because the count condition is satisfied, and releases the lock.
  6.  T2 receives the signal and wakes up, but since T3 already enqueued an item, the count has increased, and T2 must wait again in await().

It seems to me that this scenario could occur regardless of whether ReentrantLock is in fair mode or not. Has the improvement in AQS addressed this type of contention scenario to prevent such starvation issues, or is this still a possible outcome?

________________________________

Your insights into "unbounded unfairness" have also provided me with a lot of food for thought, and I?m grateful for the opportunity to reflect on these issues.

In your view, would the thread contention scenario I?ve described fall under the category of unbounded unfairness, or would it be considered an acceptable level of contention?


Once again, thank you for all the knowledge and understanding I've gained through your feedback. I'm truly grateful for your time and expertise.



Best regards,
Kim Minju


2024? 9? 6? (?) ?? 4:52, Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>?? ??:
Archie,

I should've been more specific?Condition-as-implemented-by-ReentrantLock (in fair mode) provides stronger (for some definition of stronger) semantics that the Condition interface specifies.

Since it's related, I've recently integrated a hardening of AQS and AQLS reacquisition logic in await().

Given what you presented earlier about the detection of "producer parked" it's likely that the conclusion is that ABQ works as expected.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Archie Cobbs <archie.cobbs at gmail.com<mailto:archie.cobbs at gmail.com>>
Sent: Thursday, 5 September 2024 21:23
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: ??? <miiiinju00 at gmail.com<mailto:miiiinju00 at gmail.com>>; Daniel FUCHS <daniel.fuchs at oracle.com<mailto:daniel.fuchs at oracle.com>>; 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: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Apologies in advance if I'm misunderstanding anything...

On Thu, Sep 5, 2024 at 2:05?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
 Thread state polling aside, for as long as Condition::await() is allowed to spuriously wake, FIFO just cannot be "guaranteed".

What about this statement in the Javadoc for ReentrantLock.newCondition():

The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.

So what you're saying is that a spurious wakeup on a Condition is not the same thing as a spurious signal() on a Condition; if it were, then the above statement would apply and FIFO ordering would be preserved.

Of course, a spurious wakeup would not find the condition being waited on satisfied unless there was a big coincidence. So an ordering violation that actually mattered should be exceedingly rare.

Anyway, this does seem to be a glitch in how things are supposed to work. That is: there can be no guaranteed ordering for Condition waiters when there can be spurious wakeups.

Maybe this corner case should be documented. Or better yet, fix the bug by requiring Condition to "filter out" spurious wakeups if preserving FIFO ordering (it should be possible).

-Archie

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240906/d9d45a44/attachment-0001.htm>

From liach at openjdk.org  Fri Sep  6 11:51:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 11:51:51 GMT
Subject: RFR: 8339642: Reduce overheads in InvokerBytecodeGenerator
In-Reply-To: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
References: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
Message-ID: <pIjKwYKHJyz7oqbrbOmnYf3oDYm--My-J4Rou8Gk1i0=.98af0ab0-8df8-4445-ac54-b902a0a659ca@github.com>

On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
> - `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
> - Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
> - Various minor optimizations helping reduce bytecode size and speed up interpreter execution

A few straightforward wins by shifting expensive calls.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20887#pullrequestreview-2286082146

From pminborg at openjdk.org  Fri Sep  6 11:52:35 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 6 Sep 2024 11:52:35 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v10]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <u2GPnd_uLMh7y_oOWKYckUOLkHLAplLlYyAcVkYKjMw=.0265e9bc-cc52-475f-bf91-b7e7c470f8ad@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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

  Use unaligned ops and rename benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/e8d7777c..f40573c4

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

  Stats: 19 lines in 4 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

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

From duke at openjdk.org  Fri Sep  6 11:54:52 2024
From: duke at openjdk.org (duke)
Date: Fri, 6 Sep 2024 11:54:52 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v8]
In-Reply-To: <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
Message-ID: <F6ZcflDyNI279STtvpDffq3-JfeFXe8PNizHhAAL5oo=.5d967623-2d08-4257-8820-9d1398a687af@github.com>

On Thu, 5 Sep 2024 05:07:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove benchmark

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

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

PR Comment: https://git.openjdk.org/jdk/pull/20747#issuecomment-2333888026

From liach at openjdk.org  Fri Sep  6 11:59:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 11:59:50 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy
In-Reply-To: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
Message-ID: <NdlX_UL9SEuqbSfe1Xu-tev0vXvkP1iWPyWtlDkF9dA=.95c8b819-5c6e-4642-87a3-8ccaedaf29cb@github.com>

On Fri, 6 Sep 2024 07:39:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1257:

> 1255:                 if (handlePair != null) {
> 1256:                     try {
> 1257:                         var instance = handlePair.constructor.invokeBasic(constants);

Hmm, `invokeBasic` notes ask to call with plain `Object` but `constants` is a `Object[]`... Don't know how that really worked out. Should we explicitly cast to `Object` as javac treats this as a sigpoly method (using the invocation type)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20884#discussion_r1747000956

From redestad at openjdk.org  Fri Sep  6 12:03:56 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:03:56 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v8]
In-Reply-To: <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
Message-ID: <LVfnMtE8gRp_1Rr7bZ_97stf66UFx5u5uWX2bZ572T4=.17fcb965-1745-4f33-a83d-85200a9ab124@github.com>

On Thu, 5 Sep 2024 05:07:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove benchmark

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20747#pullrequestreview-2286100300

From liach at openjdk.org  Fri Sep  6 12:03:57 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 12:03:57 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v8]
In-Reply-To: <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
 <k8-Md56hW9kjVyP6UYOgTFdQQcS0A3ymP26k5ubElYQ=.a0bb021a-d35b-4e0c-890e-d8e3799ac0ed@github.com>
Message-ID: <Bm0t-9h2mEcRQ8r8dsYHP1lCKuRKePmd3hqi2iC5vV4=.5e549af5-2371-4646-9c3b-f699884edbc2@github.com>

On Thu, 5 Sep 2024 05:07:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove benchmark

Thanks for this cleanup!

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

PR Comment: https://git.openjdk.org/jdk/pull/20747#issuecomment-2333900840

From swen at openjdk.org  Fri Sep  6 12:03:57 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 12:03:57 GMT
Subject: Integrated: 8339168: Optimize ClassFile Util slotSize
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <9OU_Dkll5HUEbnzHIVeu5WB8faRu-eZpVU4jti8goEo=.8959c825-9881-421d-861f-001159c39fc1@github.com>

On Wed, 28 Aug 2024 13:12:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

This pull request has now been integrated.

Changeset: febbd998
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/febbd998ee72054353e816e9b7b588c9ea2c0500
Stats:     25 lines in 2 files changed: 9 ins; 5 del; 11 mod

8339168: Optimize ClassFile Util slotSize

Reviewed-by: liach, redestad

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

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

From redestad at openjdk.org  Fri Sep  6 12:06:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:06:25 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy [v2]
In-Reply-To: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
Message-ID: <A3FV7pDobLs9qzACbauYdodTdjuZSyJnXsD2NbLA2Sw=.49c870de-0207-4643-9bdf-af2932cbaa5d@github.com>

> Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.

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

  Explicitly cast to Object

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20884/files
  - new: https://git.openjdk.org/jdk/pull/20884/files/c53f99f7..8bf73809

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

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

PR: https://git.openjdk.org/jdk/pull/20884

From redestad at openjdk.org  Fri Sep  6 12:06:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:06:25 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy [v2]
In-Reply-To: <NdlX_UL9SEuqbSfe1Xu-tev0vXvkP1iWPyWtlDkF9dA=.95c8b819-5c6e-4642-87a3-8ccaedaf29cb@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
 <NdlX_UL9SEuqbSfe1Xu-tev0vXvkP1iWPyWtlDkF9dA=.95c8b819-5c6e-4642-87a3-8ccaedaf29cb@github.com>
Message-ID: <uXFZJ15Ol71rWX0-EfmYy0POJOCFluLuCzisQLv6pDE=.c147bf48-216d-45ac-9391-4df93b84f4bc@github.com>

On Fri, 6 Sep 2024 11:56:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicitly cast to Object
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1257:
> 
>> 1255:                 if (handlePair != null) {
>> 1256:                     try {
>> 1257:                         var instance = handlePair.constructor.invokeBasic(constants);
> 
> Hmm, `invokeBasic` notes ask to call with plain `Object` but `constants` is a `Object[]`... Don't know how that really worked out. Should we explicitly cast to `Object` as javac treats this as a sigpoly method (using the invocation type)?

I tried with/without `(Object)constants` and didn't see any difference in instrumentation. It makes it more obviously correct so I'll add it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20884#discussion_r1747007864

From redestad at openjdk.org  Fri Sep  6 12:06:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:06:53 GMT
Subject: RFR: 8339592: Simplify and remove unused code in
 ObjectMethods.<clinit>
In-Reply-To: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>
References: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>
Message-ID: <ibMHSWhnw3StiTBAzu7yRCVmXt7cTOGTnLPYvJOkSv4=.09841f49-3c2e-4cc1-ad88-cef9a01c6b0e@github.com>

On Thu, 5 Sep 2024 08:19:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few trivial(?) cleanups to `java.lang.runtime.ObjectMethods`:
> - Avoid `MethodType.fromMethodDescriptorString` which needs a classloader
> - Use `MethodHandles.zero`
> - Remove unused static `MethodHandles` and `MethodTypes`

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20866#issuecomment-2333905808

From redestad at openjdk.org  Fri Sep  6 12:06:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:06:53 GMT
Subject: Integrated: 8339592: Simplify and remove unused code in
 ObjectMethods.<clinit>
In-Reply-To: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>
References: <BTMjWkJ0d1zUnZxegumfGKkYwEfzUgPZ6gNDgq1TAN8=.0dfb72d6-e9ef-4f0f-94ee-30ae7c018c20@github.com>
Message-ID: <Adi3vBecdaBQM0CMqeKYeQpKJveKwwCKojIoG8HMg3c=.375b70b7-b8fe-4146-9a94-c8fed5f6a077@github.com>

On Thu, 5 Sep 2024 08:19:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few trivial(?) cleanups to `java.lang.runtime.ObjectMethods`:
> - Avoid `MethodType.fromMethodDescriptorString` which needs a classloader
> - Use `MethodHandles.zero`
> - Remove unused static `MethodHandles` and `MethodTypes`

This pull request has now been integrated.

Changeset: 260908e1
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/260908e16ece7a0a9e6f538273b27c677db4d296
Stats:     40 lines in 1 file changed: 0 ins; 21 del; 19 mod

8339592: Simplify and remove unused code in ObjectMethods.<clinit>

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20866

From pminborg at openjdk.org  Fri Sep  6 12:07:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 6 Sep 2024 12:07:59 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
Message-ID: <mlBmQQGkv7KoKZIbVKfA96ZTM-9W57j9Mme26C-QvtE=.73bd5377-ecef-41bf-8df3-6af9aad3e53b@github.com>

On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
> 
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
> 
> Here is another chart for Linux a64:
> 
> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
> 
> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
> 
> It would be possible to use the same code path for the 7arg  `MemorySegment::copy` method if it is similar to:
> 
> 
> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
> 
> 
> This could be added in a separate PR.
> 
> This PR has been tested with tier1-3 and passed.

> Wdyt about the benchmark I have added at [#20829 (comment)](https://github.com/openjdk/jdk/pull/20829#issuecomment-2326404582)? Sadly I didn't yet run against this PR

Let's see what we can do about this later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20829#issuecomment-2333908071

From liach at openjdk.org  Fri Sep  6 12:10:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 12:10:49 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy [v2]
In-Reply-To: <A3FV7pDobLs9qzACbauYdodTdjuZSyJnXsD2NbLA2Sw=.49c870de-0207-4643-9bdf-af2932cbaa5d@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
 <A3FV7pDobLs9qzACbauYdodTdjuZSyJnXsD2NbLA2Sw=.49c870de-0207-4643-9bdf-af2932cbaa5d@github.com>
Message-ID: <F750bgNjONB204B6ebsYmsRR1ABTrGQ3zi4fiFYbMKw=.67f4c71d-c2ea-4a76-9430-2ad64008ea56@github.com>

On Fri, 6 Sep 2024 12:06:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly cast to Object

Thanks for this update.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20884#pullrequestreview-2286114700

From prappo at openjdk.org  Fri Sep  6 12:11:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 12:11:49 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

I understand that a PR might not be the best place for a comment like this. Still, it's highly relevant to the review feedback I've got so far. Also, a PR comment will be seen by more people sooner than a JBS comment. This is by the virtue of being fanned out by the mailing lists.

Some reviewers suggested fixing the typography. I could do it, but I think it will pay us more if we pause and think what the broken typography tells us, which I think is that the design of these tags is not entirely what it should be. 

Currently, these tags are really a specialised form of `@see` and `@linkplain`. The block variant corresponds to `@see` and the inline variant corresponds to `@linkplain`.

Since the tag links to a specific resource, it saves the documentation author keystrokes on typing the link to that resource. Along with the visual consistency of the generated documentation, the author also gets some integrity: the tag links to the same version of the specification as that of the documentation.

Unfortunately, mismatching versions is not the only source of broken integrity. Even if initially the tag is accurate, it may degrade over time by various means. This PR is a good evidence that specification sections can be reordered and that their text can be changed. The problem is not the degradation per se, but that it stays unnoticed indefinitely.

In similar situations, we use external checkers as a post-build documentation test. While it's much better than nothing and is more flexible than changing the tags, failing tests are prone to stay problem-listed indefinitely. Which gets us back to square one.

If like me you think that a broken or irrelevant link is bad, we could make these tags provide more integrity. The tags could check their contents against the actual specification and report an error if the contents are not the same (subject to some typographic and formatting leeway). As for the visual consistency, the tags could also make sure the text they generate is of a particular form by automatically carrying over (some) typography from the specification to the generated documentation.

In my mind, this will require having (an extract from) the specification accessible to the tag. Because build system don't typically have access to the Internet, the specification could be stored in the repo and updated every release, which happens every 6 months.

One problem though is what to do when (not if) a spec is not up-to-date. For example, consider these `@jls` tags in JDK 23:

    package java.lang.runtime;
       ...
     * @jls 5.7.1 Exact Testing Conversions
     * @jls 5.7.2 Unconditionally Exact Testing Conversions
       ...
     * @since 23
     */
    public final class ExactConversionsSupport {

These tags relate to a preview feature, which is documented not in JLS but in an annex to it, which is currently missing due to a build error. If the tags are to strictly check their integrity, a problem like this would prevent a documentation build.

Thoughts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2333914768

From redestad at openjdk.org  Fri Sep  6 12:22:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:22:54 GMT
Subject: RFR: 8339642: Reduce overheads in InvokerBytecodeGenerator
In-Reply-To: <qk5BERfMRVXCDbX-ZeI-CvoRlF2ZFmJEiYYgeF1pqSo=.9773ad3d-20cf-44c0-a6ad-1f3281cc5655@github.com>
References: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
 <qk5BERfMRVXCDbX-ZeI-CvoRlF2ZFmJEiYYgeF1pqSo=.9773ad3d-20cf-44c0-a6ad-1f3281cc5655@github.com>
Message-ID: <zMjNTpgBjnpCir3uuxtxeLmBiKlnQ5m25j4hUp8Tnco=.5202717a-d903-4471-8298-869dfe5d2a37@github.com>

On Fri, 6 Sep 2024 10:42:54 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> - A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
>> - `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
>> - Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
>> - Various minor optimizations helping reduce bytecode size and speed up interpreter execution
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 149:
> 
>> 147:         localsMap[0] = 0; // localsMap has at least one element
>> 148:         for (int i = 1, index = 0; i < localsMap.length; i++) {
>> 149:             Class<?> cl = mt.parameterType(i - 1);
> 
> Can we use var?
> 
> var cl = mt.parameterType(i - 1);

I'm not too keen on `var` when it's not immediately obvious what the type is. For these two places I think `var` would make type information slightly less obvious when reading the code, so I'll opt to leave it as-is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20887#discussion_r1747032114

From redestad at openjdk.org  Fri Sep  6 12:30:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:30:53 GMT
Subject: RFR: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy [v2]
In-Reply-To: <A3FV7pDobLs9qzACbauYdodTdjuZSyJnXsD2NbLA2Sw=.49c870de-0207-4643-9bdf-af2932cbaa5d@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
 <A3FV7pDobLs9qzACbauYdodTdjuZSyJnXsD2NbLA2Sw=.49c870de-0207-4643-9bdf-af2932cbaa5d@github.com>
Message-ID: <X4kmY0_k6lsWI6cmaBPbyPe9I3yc0VcZLQJ1oaOk-s8=.a0044875-5ac2-4fe9-a08f-ad7da13097a3@github.com>

On Fri, 6 Sep 2024 12:06:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly cast to Object

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20884#issuecomment-2333943581

From redestad at openjdk.org  Fri Sep  6 12:30:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:30:53 GMT
Subject: Integrated: 8339640: Reduce construction overheads in
 StringConcatFactory$InlineHiddenClassStrategy
In-Reply-To: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
References: <6yGNis5CbAlWRNRBpjH4G7biwLRIdXDoSPArGMwV9uM=.f4b0d08e-8d6e-4375-be9b-02710cb63e21@github.com>
Message-ID: <nbLTJGEP-xpsWV1hE5BDgvopV0pwGxf2791DVrR8p-8=.cb867430-20a6-446a-a961-99541b99529b@github.com>

On Fri, 6 Sep 2024 07:39:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Using the trusted `invokeBasic` method streamlines invokers and avoids spinning up of some type conversion handles. This reduces classes generated in a few scalability stress tests.

This pull request has now been integrated.

Changeset: cb00333d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb00333d6a47760cb2ab17e867ea8dab32289f98
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8339640: Reduce construction overheads in StringConcatFactory$InlineHiddenClassStrategy

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20884

From redestad at openjdk.org  Fri Sep  6 12:37:52 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:37:52 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v7]
In-Reply-To: <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
Message-ID: <vEUGJy8V5gd_oDsRG5rb5m_eVYUgsWvQs9knAV5rMCg=.05c5388e-60b2-4600-b039-1a79170b2d6d@github.com>

On Thu, 5 Sep 2024 22:47:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge remote-tracking branch 'origin/class_file_buf_writer_imp_202408_patch_int' into class_file_buf_writer_imp_202408_patch_int
>  - Eliminate redundant variables
>  - buf skip
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - revert skip
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Suggestions from @cl4es
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/8fb8cd85...e7f57a6f

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20780#pullrequestreview-2286163711

From redestad at openjdk.org  Fri Sep  6 12:40:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:40:55 GMT
Subject: RFR: 8339642: Reduce overheads in InvokerBytecodeGenerator
In-Reply-To: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
References: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
Message-ID: <M18MA9u0b0yRVaOEYdRDf8UrSpE5T8r49QNcHvleXYw=.0cbdbb99-abee-4c64-ab56-121e070518d4@github.com>

On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
> - `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
> - Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
> - Various minor optimizations helping reduce bytecode size and speed up interpreter execution

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20887#issuecomment-2333959845

From redestad at openjdk.org  Fri Sep  6 12:40:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 12:40:55 GMT
Subject: Integrated: 8339642: Reduce overheads in InvokerBytecodeGenerator
In-Reply-To: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
References: <wbt1D8ldn07N-tUtoqTMvW5i4A7znIBRU5oJ2PcRxLs=.bcad4a9f-223d-4532-a50e-7bc317a24e7a@github.com>
Message-ID: <VN_DWg2EQGbSSh3TrfX_uMu1r2yImBk2pLcTeiuIeks=.88f7cede-2f5e-43cb-a897-6001e7d5e950@github.com>

On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - A small portion (~5%) of the instrumented overhead when spinning MH/LF classes in `InvokeBytecodeGenerator` comes from creating the exact same `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of constants has a small but measurable impact.
> - `classDesc(MemberName.class)` is called ~8000 times during an OpenJDK build, `classDesc(MethodType.class)` ~900 - special casing looks profitable
> - Class name validation narrowed down, use ReferenceClassDescImpl.ofValidated
> - Various minor optimizations helping reduce bytecode size and speed up interpreter execution

This pull request has now been integrated.

Changeset: d2b36f09
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2b36f09072e03370ee02b063fcc4a1f0e6cb2ee
Stats:     75 lines in 2 files changed: 30 ins; 32 del; 13 mod

8339642: Reduce overheads in InvokerBytecodeGenerator

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20887

From nbenalla at openjdk.org  Fri Sep  6 12:42:52 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 6 Sep 2024 12:42:52 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
 <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
Message-ID: <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>

On Fri, 6 Sep 2024 09:14:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   convert TestNullHostile to use JUnit Jupiter API
>
> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 681:
> 
>> 679:      */
>> 680:     static AnnotationValue of(Object value) {
>> 681:         requireNonNull(value);
> 
> Below is a null test throwing IAE.

The test fails if the method does not throw an exception or throws anything other than a NPE. That's why I added `requireNonNull` here.

What exceptions would be considered ok when nulls are provided?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1747059399

From sgehwolf at openjdk.org  Fri Sep  6 12:56:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 6 Sep 2024 12:56:53 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
Message-ID: <e-RI3tLDwClyu-38PbSM0nFLtJRcxZZjLfwwpznf3G8=.29756e9a-49a6-437c-ad2c-34e6ffe5f464@github.com>

On Fri, 30 Aug 2024 11:05:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Add Whitebox check for host cpu
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comments
>>  - 8333446: Add tests for hierarchical container support
>
> Looking through the coding it looks more or less okay to me; but if you really need to run it under user 'root'  I think we will not have so much use for this in our test environments  because we use other test users.
> Not saying that this is a very bad thing,  maybe it is just the way it is, that 'root' is needed ?

Thank you for the review, @MBaesken!

@zzambers OK for you as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2333989946

From duke at openjdk.org  Fri Sep  6 12:57:53 2024
From: duke at openjdk.org (duke)
Date: Fri, 6 Sep 2024 12:57:53 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v7]
In-Reply-To: <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
Message-ID: <fs5cwDCyfh5h966JCdT9O2Jwo7Xv8ZjaNc8CgF5WNR8=.6156cc22-51a2-439a-beb9-ec0f7dfe29d0@github.com>

On Thu, 5 Sep 2024 22:47:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge remote-tracking branch 'origin/class_file_buf_writer_imp_202408_patch_int' into class_file_buf_writer_imp_202408_patch_int
>  - Eliminate redundant variables
>  - buf skip
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - revert skip
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Suggestions from @cl4es
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/8fb8cd85...e7f57a6f

@wenshao 
Your change (at version e7f57a6f8db449653553d30a9dbcfab754316967) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20780#issuecomment-2333991338

From kcr at openjdk.org  Fri Sep  6 13:18:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Sep 2024 13:18:49 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
 <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com>
Message-ID: <WhG8jlLAttk0bO_beHeYTh7G3lhWR-uRvJdPqVr_wj4=.2a8b5a00-5382-46df-8e39-abcfa76fc64b@github.com>

On Fri, 6 Sep 2024 01:52:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Looks good. I'll review the CSR when its ready.

Thanks.

> The changes to make jdk.jsobject an upgradeable module looks right.

Thanks for checking. My testing primarily focused on this aspect of the change, so it's pretty well tested.

> I was initially surprised by the wording "will be delivered with JavaFX" but after playing with a few alternatives I concluded that what we have is okay.

Yeah, I tried a few variants and couldn't come up with anything better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2334035899

From duke at openjdk.org  Fri Sep  6 13:25:54 2024
From: duke at openjdk.org (Jens Lidestrom)
Date: Fri, 6 Sep 2024 13:25:54 GMT
Subject: RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
Message-ID: <LCngQQtixNQTmIfVcIEOwvZSFtxysjTaNAy5fyujczs=.06df29b2-6122-47bb-95ef-31294a0ed91b@github.com>

On Tue, 27 Aug 2024 23:49:50 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 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

src/java.base/share/classes/java/time/LocalDateTime.java line 2028:

> 2026:         SharedSecrets.setJavaTimeAccess(new JavaTimeAccess() {
> 2027:             public void formatTo(StringBuilder buf, LocalDateTime ldt) {
> 2028:                 ldt.formatTo(buf);

Neither java.time nor the rest of the JDK has a convention to use acronyms like `ldt` as variable names.

Maybe this variable should be called for example `timeToFormat` instead?

src/java.base/share/classes/jdk/internal/access/JavaTimeAccess.java line 34:

> 32:      * Prints the toString result to the given buf, avoiding extra string allocations.
> 33:      */
> 34:     void formatTo(StringBuilder buf, LocalDateTime ldt);

Neither java.time nor the rest of the JDK has a convention to use acronyms like `ldt` as variable names.

Maybe this variable should be called for example `timeToFormat` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1747120332
PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1747121067

From liach at openjdk.org  Fri Sep  6 13:40:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 13:40:59 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer [v7]
In-Reply-To: <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
 <tV_tgFefaiFhRhUZTW-IIEDwk9WPGFITY_vh7lT3kZE=.af2a7e91-eddf-4680-b177-dc83752b83b3@github.com>
Message-ID: <EtnTPOK-8kZlLWFImWhZlc5lBdc_3jRGs3BdY23EoBY=.05483cce-6480-4214-96df-6aee6f1e96da@github.com>

On Thu, 5 Sep 2024 22:47:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge remote-tracking branch 'origin/class_file_buf_writer_imp_202408_patch_int' into class_file_buf_writer_imp_202408_patch_int
>  - Eliminate redundant variables
>  - buf skip
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - Merge remote-tracking branch 'upstream/master' into class_file_buf_writer_imp_202408_patch_int
>  - revert skip
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Suggestions from @cl4es
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/8fb8cd85...e7f57a6f

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20780#pullrequestreview-2286296261

From swen at openjdk.org  Fri Sep  6 13:41:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 13:41:00 GMT
Subject: Integrated: 8339317: Optimize ClassFile writeBuffer
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <bMr9Rr0at_Y_Oa06ym019pJbH91bKX4onf-xMF5D_cM=.a00defca-6603-4933-a107-16f006b961d2@github.com>

On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

This pull request has now been integrated.

Changeset: 9ebc2ecb
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ebc2ecbf613da3bcee1dd5e8920a26d5f6d6df7
Stats:     56 lines in 7 files changed: 32 ins; 4 del; 20 mod

8339317: Optimize ClassFile writeBuffer

Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20780

From liach at openjdk.org  Fri Sep  6 13:42:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 13:42:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
 <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
 <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>
Message-ID: <MPTpEtSfD5dE_nYDUjXSRC4OjM7QwCzhtOJ1mcgwEr0=.a33061ac-1f88-4375-a400-317203da1454@github.com>

On Fri, 6 Sep 2024 12:40:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 681:
>> 
>>> 679:      */
>>> 680:     static AnnotationValue of(Object value) {
>>> 681:         requireNonNull(value);
>> 
>> Below is a null test throwing IAE.
>
> The test fails if the method does not throw an exception or throws anything other than a NPE. That's why I added `requireNonNull` here.
> 
> What exceptions would be considered ok when nulls are provided?

I think we should prefer NPE instead of IAE for null inputs.

I think we should just remove this method - the format for composite list/array or annotation is not well-defined. We might replace this with a `ofResolvedConstant` to accept primitives and String.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1747146758

From asotona at openjdk.org  Fri Sep  6 13:49:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Sep 2024 13:49:53 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v3]
In-Reply-To: <MPTpEtSfD5dE_nYDUjXSRC4OjM7QwCzhtOJ1mcgwEr0=.a33061ac-1f88-4375-a400-317203da1454@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
 <L8rTqYKvoWDfVRIWlQEE0TiPqPRtwE-9LDIvOTSQlsU=.c15559b0-7993-4031-8f67-dd4811e9b836@github.com>
 <RaGqoJOwXsKmqRcSXnsVhOxwjb2vlAEycLaH-aRpyiM=.352f7db3-4e9e-46dc-8a4d-7dcc0228baf1@github.com>
 <Rp37l52aaG4mMKwm4sq5wZx7eCre26rU8Ol2bBmyx54=.80ce0d08-7131-491a-8684-ec928c1d5bf5@github.com>
 <MPTpEtSfD5dE_nYDUjXSRC4OjM7QwCzhtOJ1mcgwEr0=.a33061ac-1f88-4375-a400-317203da1454@github.com>
Message-ID: <-oHMdlEykt9iuwWT6eLH5UjHFxvxrchVv4KahXOxsEo=.78ef2f8e-faf4-4f76-8835-c80f6d4458ce@github.com>

On Fri, 6 Sep 2024 13:39:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The test fails if the method does not throw an exception or throws anything other than a NPE. That's why I added `requireNonNull` here.
>> 
>> What exceptions would be considered ok when nulls are provided?
>
> I think we should prefer NPE instead of IAE for null inputs.
> 
> I think we should just remove this method - the format for composite list/array or annotation is not well-defined. We might replace this with a `ofResolvedConstant` to accept primitives and String.

API method removal is not subject of this bug/PR, please discuss it on the mailing list.
Also throwing NPE instead of IAE is a subject for consideration, as it is a factory of AnnotationValue from an Object, where null might be considered as IAE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20556#discussion_r1747156753

From mcimadamore at openjdk.org  Fri Sep  6 14:31:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 14:31:08 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <k9YKNmPqzfp9CuOWgvklilmTVVv6ibBUXU3Jj1BwEOQ=.5f30c9ed-3aa5-46ad-83a9-3e0cfc248aee@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
 <k9YKNmPqzfp9CuOWgvklilmTVVv6ibBUXU3Jj1BwEOQ=.5f30c9ed-3aa5-46ad-83a9-3e0cfc248aee@github.com>
Message-ID: <AR7MMRtZB4TKiY43o-Ug_j31__O1kciU-0pkvv6lTd4=.bb96d0a7-2400-4a5c-a088-5e855ee99268@github.com>

On Thu, 5 Sep 2024 17:50:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix errors in a benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 179:
> 
>> 177:                 return 0;
>> 178:             }
>> 179:             i = AbstractMemorySegmentImpl.vectorizedMismatchLargeForBytes(src.sessionImpl(), dst.sessionImpl(),
> 
> We should probably move `vectorizedMismatchLargeForBytes` in this class too, for clarity

I see the method is still in `AbstractMemorySegmentImpl`. Note that if we could move it here, we can then drop (I think) `SCOPED_MEMORY_ACCESS` from `AbstractMemorySegmentImpl`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1747218277

From coleenp at openjdk.org  Fri Sep  6 14:48:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Sep 2024 14:48:14 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v5]
In-Reply-To: <IoTFziezl_Gg_LkR0Si0E07aia-_pru3xzss5u4l8iI=.533aa144-ac2d-4d7a-b34c-0eaecfdf602f@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <0VQJugX9IulwqoN4WWxCixyhPRhfGs-48Vm5DB0s-VU=.334232df-93b0-453a-aba7-0cf26cecf8d1@github.com>
 <IoTFziezl_Gg_LkR0Si0E07aia-_pru3xzss5u4l8iI=.533aa144-ac2d-4d7a-b34c-0eaecfdf602f@github.com>
Message-ID: <B1VSLU_8OGOdSDaejfC9ay4XQbhcWUbEsT7PkNXA_ME=.68e55fe2-3876-47fe-bccb-b4ca9d618f0b@github.com>

On Fri, 6 Sep 2024 11:08:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add function in Metaspace to tell you if Klass pointer is in compressible space.
>
> src/hotspot/share/memory/metaspace.hpp line 165:
> 
>> 163:     return using_class_space() && (is_in_class_space(k) || is_in_shared_metaspace(k));
>> 164:   }
>> 165: 
> 
> I propose to drop this, and instead add a utility function to `CompressedKlassPointers` like this:
> 
> 
> // Returns true if p falls into the narrow Klass encoding range
> inline bool CompressedKlassPointers::is_in_encoding_range(const void* p) {
>   return _base != nullptr && p >= _base && p < (_base + _range);
> }
> 
> (Probably  the `_base != nullptr` could even be left out, since `_range==0` and `_base==nullptr` for -UseCompressedClassPointers)
> 
> And then use that function in `jfrTraceIdKlass.cpp`. That file needs to use `CompressedKlassPointers` anyway because it needs to encode the Klass*.
> 
> This avoids having to rely on the exact composition of the memory regions inside the encoding range. What counts is whether the Klass pointer points into the narrow Klass encoding range.
> 
> Essentially, with CDS, memory looks like this:
> 
> 
> encoding                                                               encoding              
> base                                                                   end
> |-----------------------------------------------------------------------|
> |----CDS---| |--------------------class space---------------------------|

oh yes that's much better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1747241623

From liach at openjdk.org  Fri Sep  6 15:00:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 15:00:13 GMT
Subject: Integrated: 8339519: Remove size field from instructions
In-Reply-To: <d0rdAh9IYv_LBLd8W9Z58yzwPGyS8NQg2mY4fU_TXOM=.8e5513ac-6f27-4eaa-a92a-8e391df0be6c@github.com>
References: <d0rdAh9IYv_LBLd8W9Z58yzwPGyS8NQg2mY4fU_TXOM=.8e5513ac-6f27-4eaa-a92a-8e391df0be6c@github.com>
Message-ID: <ucLxzJ_dBDo3mlxtAo9biswwsT-Zu_wo8vV0ceo8zxQ=.6caf3662-8a05-45d6-8f2a-2adefb598233@github.com>

On Thu, 5 Sep 2024 23:02:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> `AbstractInstruction` has a redundant `size` field unnecessary for the majority of instructions. We should add this field to the 2 switch instructions that need it only.

This pull request has now been integrated.

Changeset: 5b72bbf9
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b72bbf9d4a4c9c966a665c8d48e5f6c0dcdba1c
Stats:     73 lines in 1 file changed: 8 ins; 12 del; 53 mod

8339519: Remove size field from instructions

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20880

From jjg at openjdk.org  Fri Sep  6 15:13:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 6 Sep 2024 15:13:04 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
 <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>
Message-ID: <0eesrQjIjIPQpmWyNkorSyQAWTCwWduwpfFHAnFdXTA=.ce7dcc1d-cbdc-4dcf-ac8f-85984a9713ab@github.com>

On Fri, 6 Sep 2024 12:09:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thoughts?

My initial thought is, at least we're working with specific tags (`@jls` and `@jvms`) rather than generic HTML links (`<a href=...>...</a>`), since that permits the kind of detailed analysis and checking you are doing.

Preview-ness is a pervasive feature of JDK these days, on the command-line and in APIs. Perhaps the tags here can be augmented to indicate that a feature is a preview feature, for example, `@jls preview 5.7.2 Unconditionally Exact Testing Conversions`. This could be used not only to affect the generated output, perhaps with <sup>PREVIEW</sup>, but could be used to help both determine the target for such links, and to review such links in subsequent releases. Such management should be part of the responsibilities of the preview-feature owner.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2334271942

From rriggs at openjdk.org  Fri Sep  6 15:13:08 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 6 Sep 2024 15:13:08 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v3]
In-Reply-To: <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
Message-ID: <KTDl09LHDnUSF2lUGR0BbcV2c3huYB9Enf7Yr16a3-k=.7842b20c-75b2-487b-8b2b-91d003afe880@github.com>

On Fri, 6 Sep 2024 07:05:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for ENOMEM

LGTM

src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c line 115:

> 113:         // Allocate buffer big enough for all processes; add a little
> 114:         // bit of space to be able to hold a few more proc infos
> 115:         // for processes started rigth after the first sysctl call

typo: "rigth"

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2286516816
PR Review Comment: https://git.openjdk.org/jdk/pull/20839#discussion_r1747278295

From duke at openjdk.org  Fri Sep  6 15:14:10 2024
From: duke at openjdk.org (Brett Okken)
Date: Fri, 6 Sep 2024 15:14:10 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
Message-ID: <AYbLj-T19q6gIcFEisoGFkkbQlpJ3Lzm-LjXwazsSE0=.61cdf34f-0c59-408b-bb2d-1150997d7e5d@github.com>

On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errors in a benchmark

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 244:

> 242:         return (Architecture.isLittleEndian()
> 243:                 ? Long.numberOfTrailingZeros(x)
> 244:                 : Long.numberOfLeadingZeros(x)) / 8;

Would there be value in having a constant LongToIntFunction lambda to capture this logic?


private static final LongToIntFunction LEADING_ZEROS = Architecture.isLittleEndian() ? Long::numberOfTrailingZeros : Long::numberOfLeadingZeros;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1747281751

From miiiinju00 at gmail.com  Fri Sep  6 16:02:45 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Sat, 7 Sep 2024 01:02:45 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>

Dear Viktor,

I hope this email finds you well. First and foremost, thank you for providing such a detailed explanation of the AQS issue.

Based on Archie's suggestion, I've taken the liberty of implementing a custom ArrayBlockingQueue3 class and created a test case that attempts to reproduce the scenario you described. I've particularly focused on the potential "barging" behavior you mentioned.

Following Archie's recommendation, I've added the following implementation to ArrayBlockingQueue3:

private final HashSet<Thread> puttingThreads = new HashSet<>();

public void put(E e) throws InterruptedException {
    Objects.requireNonNull(e);
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    final boolean added = puttingThreads.add(Thread.currentThread());
    try {
        while (count == items.length) {
            notFull.await();
        }
        enqueue(e);
    } finally {
        if (added)
            puttingThreads.remove(Thread.currentThread());
        lock.unlock();
    }
}

public boolean isPutting(Thread thread) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        return puttingThreads.contains(thread);
    } finally {
        lock.unlock();
    }
}
Using this modified implementation, I've written a test case that attempts to simulate the scenario. I've attached the full test code to this email for your reference.



--------------------------------------------------------

The issue arises in the brief moment between when the thread performing the take() decreases the count and just before it sends the signal, during which another thread calling put() can acquire the lock via lock.lockInterruptibly(). I understand that the waiting spaces for Condition.await() and the ReentrantLock are separate, which contributes to this subtle timing problem. When a thread is signaled in Condition.await(), it is transferred from the Condition's waiting queue to the lock queue, where it must reacquire the lock before proceeding.

To better understand the timing of this issue, it may be helpful to review the dequeue method inside the queue.take()method

private E dequeue() {
    // assert lock.isHeldByCurrentThread();
    // assert lock.getHoldCount() == 1;
    // assert items[takeIndex] != null;
    final Object[] items = this.items;
    @SuppressWarnings("unchecked")
    E e = (E) items[takeIndex];
    items[takeIndex] = null;
    if (++takeIndex == items.length) takeIndex = 0;
    count--;
    if (itrs != null)
        itrs.elementDequeued();
    notFull.signal();
    return e;
}
--------------------------------------------------------
Test Code

package org.main;

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.util.ArrayList;
import java.util.List;
import org.example.ArrayBlockingQueue3;
import org.junit.jupiter.api.Test;

class ThreadStarvationTest {

    @Test
    void test() throws InterruptedException {
        // Set the capacity of the queue
        int CAPACITY = 10;
        // Create an instance of ArrayBlockingQueue3 with fairness mode enabled
        ArrayBlockingQueue3<Integer> queue = new ArrayBlockingQueue3<>(CAPACITY, true);
        
        // Preload the queue to its capacity
        int PRELOAD_VALUE = -1;
        for (int i = 0; i < CAPACITY; i++) {
            queue.add(PRELOAD_VALUE);
        }

        // Create threads that are already waiting to put elements
        int ALREADY_PUT_COUNT = 10;
        int ALREADY_PUT_NUMBER = 10;
        for (int i = 0; i < ALREADY_PUT_COUNT; i++) {
            Thread thread = new Thread(() -> {
                try {
                    // put() will block because the queue is full
                    // This thread simulates T2, the thread trying to put an element while the queue is full.
                    queue.put(ALREADY_PUT_NUMBER);
                } catch (InterruptedException e) {
                    // ignore
                }
            });
            thread.start();

            // Wait until the thread is actually trying to put
            while (!queue.isPutting(thread)) ;
        }

        // Give time for all threads to enter waiting state
        Thread.sleep(2000);

        // Set up new producer threads
        final int PRODUCER_PUT_NUMBER = -999;
        final int PRODUCER_COUNT = 1000;

        final Runnable producingJob = () -> {
            try {
                // T3
                queue.put(PRODUCER_PUT_NUMBER);
            } catch (InterruptedException e) {
                // ignore
            }
        };
        // Thread to start new producer threads when consumption begins
        Thread produceWhenConsumingThread = new Thread(() -> {
            for (int i = 0; i < PRODUCER_COUNT; i++) {
                Thread thd = new Thread(producingJob);
                thd.start();
            }
        });
        
        ArrayList<Integer> result = new ArrayList<>();

        // Start new producer threads simultaneously with consumption
        produceWhenConsumingThread.start();

        // Consume elements from the queue
        for (int i = 0; i < CAPACITY + ALREADY_PUT_COUNT; i++) {
            // Can be T1
            Integer take = queue.take();
            result.add(take);
        }

        // Expected result

        List<Integer> expected = new ArrayList<>();
        // First 10 elements should be -1 (preloaded values)
        for (int i = 0; i < CAPACITY; i++) {
            expected.add(PRELOAD_VALUE);
        }
        // Next 10 elements should be 10 (from already waiting threads)
        for (int i = 0; i < ALREADY_PUT_COUNT; i++) {
            expected.add(ALREADY_PUT_NUMBER);
        }

        // Assert that the actual result matches the expected result
        assertEquals(expected, result);
    }

}

Expected :[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10]
Actual   :[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 10, 10, 10, 10, -999, -999, 10, -999, -999, 10]
The test aims to recreate the following sequence:

The queue is full, and T2 is executing put() and is waiting in Condition.await().
T1 calls queue.take(), removes an item from the queue, and just before signaling, T1 decreases the count. At this point, the queue is no longer full (count != items.length).
T3 acquires the lock via lock.lockInterruptibly().
T1 then sends the Condition.signal(), and T2 is still waiting to acquire the lock via lock.lockInterruptibly().
T3 successfully enqueues an item because the while (count == items.length) condition is not satisfied. T3 then increases the count again, making the queue full (count == items.length).
T2 finally acquires the lock via lock.lockInterruptibly(), but since the queue is full again, T2 hits the while(count == items.length) condition and goes back to Condition.await().
This sequence illustrates a potential race condition where T3 acquires the lock just after T1 decreases the count but before T1 sends the signal. Even though T2 is waiting in Condition.await() and receives the signal, I understand that the waiting spaces for Condition.await() and ReentrantLock are separate. Because of this, I believe that T3 can still acquire the lock while T2 is in await(). As a result, T3 can proceed, enqueue an item, and refill the queue, causing T2, once it acquires the lock, to find the queue full again. This race condition seems possible even with a fair lock due to the subtle timing gap between when T1 lowers the count and when it sends the signal, which would force T2 to re-enter the await() state.

Since this test involves very subtle timing issues, I found it challenging to consistently reproduce it using only three threads. Therefore, my thought was that threads that had previously called put() and were waiting should be guaranteed to enter before subsequent threads that come in during consumption. I've attempted to design the test with this intention.

I would be incredibly grateful for your insights on whether this test accurately represents the scenario you described. I'm particularly interested in your opinion on whether it might help identify any unexpected behavior.

There's a possibility that this situation might not correspond to the unbounded unfairness you mentioned. I'm unsure whether this is the intended implementation or if there might be an issue here. Your expertise on this matter would be invaluable. Because it occurs only in extremely rare and extreme cases.

If you need any clarification or if you think the test should be modified in any way, please don't hesitate to let me know. I'm more than happy to make any necessary adjustments based on your feedback.

Thank you once again for your time and patience in helping me understand this complex issue.

Best regards,

Kim Minju


> 2024. 9. 6. ?? 8:47, Viktor Klang <viktor.klang at oracle.com> ??:
> 
> Hi Kim,
> 
> The recent updated to AQS reacquisition has to do with behavior if for some reason there's an exception thrown (think SOE or OOM, or something like that), so it isn't really applicable in this case.
> 
> The queue is full, and T2 is executing put() and is waiting in Condition.await().
> T1 calls queue.take(), removes an item from the queue, and is about to send a signal()
> T3 is about to call put() and is just before lock.lockInterruptibly().
> T1 decreases the count and sends a signal(), indicating that space is available in the queue.
> T3 acquires the lock via lock.lockInterruptibly(), successfully enqueues an item because the count condition is satisfied, and releases the lock.
> T2 receives the signal and wakes up, but since T3 already enqueued an item, the count has increased, and T2 must wait again in await().
> 
> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge". (tryLock() is documented to allow barging)
> 
> Let us know if you can come up with a reproducer which says otherwise. ?
> 
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> 
> From: ??? <miiiinju00 at gmail.com>
> Sent: Friday, 6 September 2024 04:43
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: Archie Cobbs <archie.cobbs at gmail.com>; Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue
>  
> Hi Archie,
> Thanks to your valuable suggestions, I was able to come up with a much more appropriate test, and I?ve learned a great deal in the process. I truly appreciate your insights! While this approach is clearly a significant improvement over the previous one, I still feel there might be concerns about the atomicity between notFull.await() and the signaling from outside, but I can?t deny that this new approach provides much better guarantees. Your feedback has been incredibly helpful, and I?m very grateful for your time and effort. Thank you again!
> 
> 
> 
> 
> Hi Viktor,
> Thank you for sharing your thoughts, which have given me much to consider. I have a follow-up question regarding the improvements in AQS that you mentioned. Specifically, I?d like to clarify whether these improvements ensure that, in the fair mode of ReentrantLock, threads waiting on a Condition are placed back in the queue without acquiring the lock, or if the signaling thread can now immediately acquire the lock after being signaled.
> Initially, my concern was that a thread receiving a signal might still face starvation if another thread calls put() and acquires the lock before the signaled thread can do so. Here's an example scenario:
> The queue is full, and T2 is executing put() and is waiting in Condition.await().
> T1 calls queue.take(), removes an item from the queue, and is about to send a signal()
> T3 is about to call put() and is just before lock.lockInterruptibly().
> T1 decreases the count and sends a signal(), indicating that space is available in the queue.
> T3 acquires the lock via lock.lockInterruptibly(), successfully enqueues an item because the count condition is satisfied, and releases the lock.
> T2 receives the signal and wakes up, but since T3 already enqueued an item, the count has increased, and T2 must wait again in await().
> It seems to me that this scenario could occur regardless of whether ReentrantLock is in fair mode or not. Has the improvement in AQS addressed this type of contention scenario to prevent such starvation issues, or is this still a possible outcome?
> Your insights into "unbounded unfairness" have also provided me with a lot of food for thought, and I?m grateful for the opportunity to reflect on these issues. 
> In your view, would the thread contention scenario I?ve described fall under the category of unbounded unfairness, or would it be considered an acceptable level of contention?
> 
> Once again, thank you for all the knowledge and understanding I've gained through your feedback. I'm truly grateful for your time and expertise.
> 
> 
> Best regards,
> Kim Minju
> 
> 
> 2024? 9? 6? (?) ?? 4:52, Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>?? ??:
> Archie,
> 
> I should've been more specific?Condition-as-implemented-by-ReentrantLock (in fair mode) provides stronger (for some definition of stronger) semantics that the Condition interface specifies.
> 
> Since it's related, I've recently integrated a hardening of AQS and AQLS reacquisition logic in await().
> 
> Given what you presented earlier about the detection of "producer parked" it's likely that the conclusion is that ABQ works as expected.
> 
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> From: Archie Cobbs <archie.cobbs at gmail.com <mailto:archie.cobbs at gmail.com>>
> Sent: Thursday, 5 September 2024 21:23
> To: Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
> Cc: ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>>; Daniel FUCHS <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>>; 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: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue
>  
> Apologies in advance if I'm misunderstanding anything...
> 
> On Thu, Sep 5, 2024 at 2:05?PM Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>> wrote:
>  Thread state polling aside, for as long as Condition::await() is allowed to spuriously wake, FIFO just cannot be "guaranteed".
>  
> What about this statement in the Javadoc for ReentrantLock.newCondition():
> 
> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
> 
> So what you're saying is that a spurious wakeup on a Condition is not the same thing as a spurious signal() on a Condition; if it were, then the above statement would apply and FIFO ordering would be preserved.
> 
> Of course, a spurious wakeup would not find the condition being waited on satisfied unless there was a big coincidence. So an ordering violation that actually mattered should be exceedingly rare.
> 
> Anyway, this does seem to be a glitch in how things are supposed to work. That is: there can be no guaranteed ordering for Condition waiters when there can be spurious wakeups.
> 
> Maybe this corner case should be documented. Or better yet, fix the bug by requiring Condition to "filter out" spurious wakeups if preserving FIFO ordering (it should be possible).
> 
> -Archie
> 
> --
> Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240907/4c994c69/attachment-0001.htm>

From liach at openjdk.org  Fri Sep  6 16:04:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 16:04:11 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <04Yd7RQbg2OlP3ITFXQoioYo1SfsP8HwUTRejGUJKWM=.6ce414d0-b567-4a24-a066-bb4f5481c7b0@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

I think we can ignore the title style aspect for now; the key of these tags has always been to provide a correct link to the specs, so fixing trailing period or section number is more important.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2286639738

From liach at openjdk.org  Fri Sep  6 16:08:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 16:08:15 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v8]
In-Reply-To: <CdqfnJS6-jYi9lTXzo-s-xG_1eIAztgbn00P5HaeOPc=.c10b77c6-342a-48be-a35e-38369a0ab3e7@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <CdqfnJS6-jYi9lTXzo-s-xG_1eIAztgbn00P5HaeOPc=.c10b77c6-342a-48be-a35e-38369a0ab3e7@github.com>
Message-ID: <0v-W2oIiqirv4sziYKEn_DYITX9uE9lQTc8cXrkw7Jk=.6c82ec77-ff32-492d-b468-e829e63aceaa@github.com>

On Fri, 6 Sep 2024 01:12:27 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ACC_ABSTRACT

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 464:

> 462:     byte stringInitCoder();
> 463: 
> 464:     byte stringCoder(String str);

Same remark on adding javadoc here as in #20722

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1747366926

From liach at openjdk.org  Fri Sep  6 16:11:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 16:11:15 GMT
Subject: RFR: 8336275: Move common Method and Constructor fields to
 Executable [v3]
In-Reply-To: <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
 <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>
Message-ID: <9MFjLN9RDtYLkL4F-2JLeFKPGwJsjk0LFNYk_c9HMk4=.ec284df0-706e-4f8e-9432-b640cf9f771a@github.com>

On Wed, 21 Aug 2024 15:42:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
>> 
>> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
>  - Redundant transient; Update the comments to be more accurate
>  - Inline some common ctor + method fields to executable

The new model here may no longer be valid now that deconstructors and patterns are being added. May revisit only if we are sure of the new model of deconstructors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2334385336

From liach at openjdk.org  Fri Sep  6 16:11:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 16:11:16 GMT
Subject: Withdrawn: 8336275: Move common Method and Constructor fields to
 Executable
In-Reply-To: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
Message-ID: <xU5uggaRYfBoQkGt027GZWE3NSXINYOwF01KiW4zGLs=.8633b467-6790-4387-83dc-f51a8b59ac23@github.com>

On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
> 
> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20188

From bpb at openjdk.org  Fri Sep  6 16:16:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Sep 2024 16:16:34 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v2]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <MTdYG0eejoeGn54TF_FC8t6eNWwlPWXZuyd0gSd0iIA=.6d0afa63-3389-47a6-a517-578af3624ef8@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Add verbiage to class doc, delete(), and renameTo(); add implNote to isHidden(); revert isDirectory() and isFile() changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/7fdc2322..3a68877c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=00-01

  Stats: 26 lines in 1 file changed: 15 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From bpb at openjdk.org  Fri Sep  6 16:16:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Sep 2024 16:16:34 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <ema_bm-QA-0sd_0DmJ44GZVJi8MSue-bSsQVnuWsVt4=.d3169eb4-d5cb-45e7-945b-25adde480b0c@github.com>

On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

3a68877 addresses changes to `File` only; `FIS/FOS/RAF` are as yet unchanged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2334393497

From coleenp at openjdk.org  Fri Sep  6 16:20:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Sep 2024 16:20:52 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19157/files
  - new: https://git.openjdk.org/jdk/pull/19157/files/ce96165e..efa14e0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=04-05

  Stats: 19 lines in 3 files changed: 12 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19157/head:pull/19157

PR: https://git.openjdk.org/jdk/pull/19157

From aefimov at openjdk.org  Fri Sep  6 16:34:17 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 6 Sep 2024 16:34:17 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient
Message-ID: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>

This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
- The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.

- The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.

- The `DnsClient.blockingReceive` has been updated:
    - to detect if any data is received
    - to avoid contention with `Selector.close()` that could be called by a cleaner thread

- The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.

JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

-------------

Commit messages:
 - 8339538: Wrong timeout computations in DnsClient

Changes: https://git.openjdk.org/jdk/pull/20892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339538
  Stats: 232 lines in 3 files changed: 214 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From dfuchs at openjdk.org  Fri Sep  6 17:01:08 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Sep 2024 17:01:08 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <6qETkq7VNDP0WAtt_6Sln79FED60jobIsyMHQRY5G2Q=.291dd7a9-ec7c-4623-8dc7-66a86d5d8e45@github.com>

On Fri, 6 Sep 2024 16:28:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

test/jdk/com/sun/jndi/dns/ConfigTests/TimeoutWithEmptyDatagrams.java line 62:

> 60:     private static final int DNS_CLIENT_MIN_TIMEOUT = 50;
> 61: 
> 62:     private long startTime;

startTime does not need to be an instance variable: consider removing it and make it a local variable in the runTest() method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1747445029

From bpb at openjdk.org  Fri Sep  6 17:14:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Sep 2024 17:14:22 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v3]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <zQUoGOBt8cmcPJglg2MIg0UN9FJd5vbEE8MI380oE24=.6fcd976e-f344-4287-912a-10e6a9235827@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Add verbiage about links to FIS/FOS/RAF class doc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/3a68877c..2c78bac6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=01-02

  Stats: 15 lines in 3 files changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From jvernee at openjdk.org  Fri Sep  6 17:35:10 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 6 Sep 2024 17:35:10 GMT
Subject: Integrated: 8338123: Linker crash when building a downcall handle with
 many arguments in x64
In-Reply-To: <p0QPoSFPn70tvHFPFy3lVGc3Ch2HVznRxj_-Z1GAiJ0=.8b46bf40-3191-4e84-a07c-54155581d1f0@github.com>
References: <p0QPoSFPn70tvHFPFy3lVGc3Ch2HVznRxj_-Z1GAiJ0=.8b46bf40-3191-4e84-a07c-54155581d1f0@github.com>
Message-ID: <sxdzhWnIYMUy3zdLZzqniaye572MFGSyNbTGL87Ugtw=.f05359b9-1acd-431c-9d52-ab76d7b188f5@github.com>

On Tue, 3 Sep 2024 17:52:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> - Adjust downcall stub sizes based on latest version. (per method described in https://github.com/openjdk/jdk/pull/12908)
> - Beef up test for large stubs to also cover this particular case.

This pull request has now been integrated.

Changeset: 8e580ec5
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e580ec5382af1886e1bbf2fda3bce6416ced604
Stats:     31 lines in 2 files changed: 20 ins; 0 del; 11 mod

8338123: Linker crash when building a downcall handle with many arguments in x64

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/20842

From bpb at openjdk.org  Fri Sep  6 17:47:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 6 Sep 2024 17:47:35 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v4]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <RVEg2H8qkzN9o0mhWIRwA5obV5-3GiGx80KWyG6UdgM=.e9acae85-0bca-4fbe-aef2-9b16f93a9628@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Revised class level doc of File

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/2c78bac6..9737dfc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=02-03

  Stats: 11 lines in 1 file changed: 5 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From naoto at openjdk.org  Fri Sep  6 17:49:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Sep 2024 17:49:37 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules
Message-ID: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>

Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/20893/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339644
  Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20893/head:pull/20893

PR: https://git.openjdk.org/jdk/pull/20893

From jvernee at openjdk.org  Fri Sep  6 17:51:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 6 Sep 2024 17:51:15 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v5]
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  remove PC save/restore on s390

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20479/files
  - new: https://git.openjdk.org/jdk/pull/20479/files/7d191107..b3aa6b41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20479&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20479&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20479/head:pull/20479

PR: https://git.openjdk.org/jdk/pull/20479

From psandoz at openjdk.org  Fri Sep  6 18:02:12 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 18:02:12 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v7]
In-Reply-To: <sukwAqcHLqQxTht04JBypenXM-qHztU2cX0MU1I5FAM=.85b57291-c675-44d3-8124-8d716872d280@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <W6R98NPqSYtkB0KszHdJA1XjB8X69i2ds68xM0Z4gOQ=.751d3ca0-a7a7-4bcd-a18d-11789c515b8d@github.com>
 <kdiE57Wre-w-95zW4cgbsLEfYhdKWt-Fpfk8WOWDxbE=.456c5a1b-9077-40f4-9e10-01c9fcf5cdf4@github.com>
 <sukwAqcHLqQxTht04JBypenXM-qHztU2cX0MU1I5FAM=.85b57291-c675-44d3-8124-8d716872d280@github.com>
Message-ID: <RUrI9l_7uV8rMpKTSsncI3tu0lwi87kOG-hmjRyC7-g=.da97fcec-bd2b-4ace-8dc2-46aac18edb55@github.com>

On Fri, 6 Sep 2024 06:40:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathUtils.java line 78:
>> 
>>> 76:      * @since 24
>>> 77:      */
>>> 78:     public static long addSaturating(long a, long b) {
>> 
>> Are these public methods any Java dev could use? If so: do we have tests for them?
>
> Made them package private. These routines are exercised by newly added jtreg tests.

These methods need to be public, as the need to be used in any tail computation. Recommend naming as `VectorMath` aligning with the naming of `Math` and `StrictMath`.


 * The class {@code VectorMath} contains methods for performing
 * scalar numeric operations in support of vector numeric operations.


For each method we can reference the associated vector operator.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1747520954

From naoto at openjdk.org  Fri Sep  6 18:10:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Sep 2024 18:10:33 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v2]
In-Reply-To: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
Message-ID: <FoLFe2-bLZYEKbbd4KOQf-9WCwjPp1_xh3oiYsytAlw=.583bbc1d-4b9a-4c32-9441-a73da17f6d7e@github.com>

> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixing failing test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20893/files
  - new: https://git.openjdk.org/jdk/pull/20893/files/22419a93..8e711667

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=00-01

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20893/head:pull/20893

PR: https://git.openjdk.org/jdk/pull/20893

From jbhateja at openjdk.org  Fri Sep  6 18:13:34 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Sep 2024 18:13:34 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v8]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <yQY-Q1-MIRyJmsvqMsSNXabjOX2pDMnZwIAOCd4VFK8=.a0634119-4f6f-4e54-88d0-0a6859167537@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review resolutions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/8d71f175..d3ee3104

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=06-07

  Stats: 115 lines in 18 files changed: 12 ins; 15 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Fri Sep  6 18:13:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Sep 2024 18:13:35 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
Message-ID: <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>

On Fri, 30 Aug 2024 14:40:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding descriptive comments
>
> src/hotspot/share/opto/vectornode.cpp line 2159:
> 
>> 2157: 
>> 2158:   vmask_type = TypeVect::makemask(elem_bt, num_elem);
>> 2159:   mask = phase->transform(new VectorMaskCastNode(mask, vmask_type));
> 
> I would just have two variables, and not overwrite it: `integral_vmask_type` and `vmask_type`. Maybe also `mask` could be split into two variables?

I think the variable names are appropriate and in accordance with convention.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 2770:
> 
>> 2768: 
>> 2769:     /**
>> 2770:      * Rearranges the lane elements of two vectors, selecting lanes
> 
> I have a bit of a name concern here. Why are we calling it "select" and not "rearrange"? Because for a single "from" vector we also call it "rearrange", right? Is "select" not often synonymous to "blend", which works also with two "from" vectors, but with a mask and not indexing for "selection/rearranging"?

We already have another flavor of [selectFrom](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html#selectFrom(jdk.incubator.vector.Vector)) which permutes single vector, new API extents its semantics to two vector selection, so we kept the nomenclature consistent.

> test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 324:
> 
>> 322:                     boolean is_exceptional_idx = (int)order[idx] >= vector_len;
>> 323:                     int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
>> 324:                     Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]));
> 
> I thought general Java style is camelCase? Is that not followed in the VectorAPI code?

I agree, but somehow we are using non camelCase conventions in this file, look for uses of 'vector_len'.  just preserving file level convention.

> test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 1048:
> 
>> 1046:         return SHORT_GENERATOR_SELECT_FROM_TRIPLES.stream().map(List::toArray).
>> 1047:                 toArray(Object[][]::new);
>> 1048:     }
> 
> Just a control question: does this also occasionally generate examples with out-of-bounds indices? Negative out of bounds and positive out of bounds?

Original API did throw IndexOutOfBoundsException, but later on we have moved away from exception throwing semantics to wrapping semantics.
Please find details at following comment
https://github.com/openjdk/jdk/pull/20508#issuecomment-2306344606

> test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 5812:
> 
>> 5810:                 ShortVector bv = ShortVector.fromArray(SPECIES, b, i);
>> 5811:                 ShortVector idxv = ShortVector.fromArray(SPECIES, idx, i);
>> 5812:                 idxv.selectFrom(av, bv).intoArray(r, i);
> 
> Would this test catch a bug where the backend would generate vectors that are too long or too short?

Existing vectorAPI inline expansion entry points explicitly pass lane type and count as intrinsic arguments, this is used to create concrete ideal vector types.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532692
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532456
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532419
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532340
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532307

From jbhateja at openjdk.org  Fri Sep  6 18:13:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Sep 2024 18:13:35 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <tzd9C0Mpn-SIVqeg-446ZA9PJhNl9qcsbgH3E7q-_IY=.55d0c7eb-ec36-4e37-a4e4-9ed42c35866e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <tzd9C0Mpn-SIVqeg-446ZA9PJhNl9qcsbgH3E7q-_IY=.55d0c7eb-ec36-4e37-a4e4-9ed42c35866e@github.com>
Message-ID: <bWeM1XqeP7KJNSDfQXC2rMdkgKywV2egyBLZsGppHMQ=.ae6e41df-e5da-4487-95c4-a7795f55ce42@github.com>

On Fri, 30 Aug 2024 14:57:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2183:
>> 
>>> 2181:     };
>>> 2182:     // Targets emulating unsupported permutation for certain vector types
>>> 2183:     // may need to message the indexes to match the users intent.
>> 
>> Suggestion:
>> 
>>     // may need to massage the indexes to match the users intent.
>
> This optimization for now seems quite specific to your `SelectFromTwoVectorNode::Ideal` lowering code. Can this conversion not be done there already?
> 
> What is the semantics of `VectorRearrangeNode`? Should its shuffle vector always be bytes, and we now violated that "for a quick second"? Or is it going to be generally the idea to create all sorts of shuffle types and then fix that up? But then why do we need the `vector_indexes_needs_massaging`?
> 
> Can you help me understand the concept/strategy behind this?

Ok, IIRC variable index permutation instruction on every target expects shape conformance b/w data vector and permute index vector.  Rearrange expects indices to be passed throug shuffle,  idealization routines automatically injects a VectorLoadShuffle after loading indexes held in shuffle's backing storage i.e. a byte array. 

In all the cases apart from byte vector permute , VectorLoadShuffle expands the index byte lanes to match the data vector lane. So we always end up emitting a lane expansion instruction before permute instruction (scenario 1). Apart from usual expansions VectorLoadShuffle may also do additional magic for some targets where it may need to prune / massage the index vector if target does not support destination vector type (scenario 2).

For our case, new selectFrom accepts the indices though vectors which save redundant expansions, but to leverage existing backend support for scenario 2 we do target specific pruning

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532612

From duke at openjdk.org  Fri Sep  6 18:14:10 2024
From: duke at openjdk.org (duke)
Date: Fri, 6 Sep 2024 18:14:10 GMT
Subject: RFR: 8339635: StringConcatFactory optimization for CompactStrings
 off [v2]
In-Reply-To: <Nvra7DQlboy3kBvDEPizVWWhNBEdEud9WuZ4bP3Oesc=.e2d4e6bb-a494-4760-bd90-37ca23b2a7ea@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
 <Nvra7DQlboy3kBvDEPizVWWhNBEdEud9WuZ4bP3Oesc=.e2d4e6bb-a494-4760-bd90-37ca23b2a7ea@github.com>
Message-ID: <pbHYeQtfGMqNtkUCGy8RV883ipOQSiduZC5UfzFZWOU=.14459358-5065-482f-9010-f3865c9de904@github.com>

On Fri, 6 Sep 2024 00:21:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add java doc

@wenshao 
Your change (at version 32979c13cd904980b36f59150ce76c435981416f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20722#issuecomment-2334581528

From jlu at openjdk.org  Fri Sep  6 18:32:04 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Sep 2024 18:32:04 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v2]
In-Reply-To: <FoLFe2-bLZYEKbbd4KOQf-9WCwjPp1_xh3oiYsytAlw=.583bbc1d-4b9a-4c32-9441-a73da17f6d7e@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
 <FoLFe2-bLZYEKbbd4KOQf-9WCwjPp1_xh3oiYsytAlw=.583bbc1d-4b9a-4c32-9441-a73da17f6d7e@github.com>
Message-ID: <yCtF6OYb52y95khJSMD0cla1Wdlk1D25DNJ02YlYwvw=.186aac62-20e4-47d3-83ae-34398ecae6c7@github.com>

On Fri, 6 Sep 2024 18:10:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing failing test

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2286928368

From coffeys at openjdk.org  Fri Sep  6 18:38:06 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 6 Sep 2024 18:38:06 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v2]
In-Reply-To: <FoLFe2-bLZYEKbbd4KOQf-9WCwjPp1_xh3oiYsytAlw=.583bbc1d-4b9a-4c32-9441-a73da17f6d7e@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
 <FoLFe2-bLZYEKbbd4KOQf-9WCwjPp1_xh3oiYsytAlw=.583bbc1d-4b9a-4c32-9441-a73da17f6d7e@github.com>
Message-ID: <vK6gXvbBrbUziGLOiHUaBpkpEMnVLaebDbeVR9MEbfo=.0c70f168-9e9b-49c6-aa05-3505c79bf362@github.com>

On Fri, 6 Sep 2024 18:10:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing failing test

Thanks for fixing up. Looks good!

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2286938200

From swen at openjdk.org  Fri Sep  6 18:40:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 18:40:10 GMT
Subject: Integrated: 8339635: StringConcatFactory optimization for
 CompactStrings off
In-Reply-To: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
References: <Tpq911BifEYGL2OoCXRLtZjbWtN6jpYwdBVNT0qVSfE=.2500f06c-14be-46d5-babf-3016ac30b0c4@github.com>
Message-ID: <dnMn4qSP2D9zDbRv2gwuWkOS47WYErhJN80NCmcfSKM=.90c0080c-6803-4f59-90fc-118ffbcf621d@github.com>

On Tue, 27 Aug 2024 05:08:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, when CompactStrings is turned off, the coder method is not generated, which improves the startup performance

This pull request has now been integrated.

Changeset: fbe26293
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe2629303bcee5855673b7e37d8c49f19dc9849
Stats:     15 lines in 3 files changed: 14 ins; 0 del; 1 mod

8339635: StringConcatFactory optimization for CompactStrings off

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20722

From qamai at openjdk.org  Fri Sep  6 18:41:49 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Sep 2024 18:41:49 GMT
Subject: RFR: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and laneHelper
 should use Double::doubleToRawLongBits/Float::floatToRawIntBits
Message-ID: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>

Hi,

This patch fixes an issue where we mistakenly use `Double::doubleToLongBits` in `DoubleXXXVector::withLaneHelper` and `DoubleXXXVector::laneHelper`. We should use the raw bit version instead.

Please kindly review, thanks very much.

-------------

Commit messages:
 - fix withLane and lane of floating points

Changes: https://git.openjdk.org/jdk/pull/20895/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20895&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339677
  Stats: 1997 lines in 65 files changed: 373 ins; 1302 del; 322 mod
  Patch: https://git.openjdk.org/jdk/pull/20895.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20895/head:pull/20895

PR: https://git.openjdk.org/jdk/pull/20895

From sviswanathan at openjdk.org  Fri Sep  6 18:43:09 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Sep 2024 18:43:09 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v8]
In-Reply-To: <nOA8eBHYej8JEaxzqPMjf5Xs6D5xG17gpYkM6cc-G7w=.ccd0421c-7814-449d-a4d5-4176d1148659@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <nOA8eBHYej8JEaxzqPMjf5Xs6D5xG17gpYkM6cc-G7w=.ccd0421c-7814-449d-a4d5-4176d1148659@github.com>
Message-ID: <_DbK4ZSVvMwabc8jXhGrqJD-ox6o9Bvo9or64AKUQ4E=.8bd87542-9eed-456d-8d87-a065da637918@github.com>

On Fri, 6 Sep 2024 06:43:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

I have only one comment, rest of the changes look good to me.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathUtils.java line 33:

> 31:  *
> 32:  */
> 33: public class VectorMathUtils {

Could the class also be not public as it has only package private methods now?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2286943136
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1747565468

From sviswanathan at openjdk.org  Fri Sep  6 18:47:12 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Sep 2024 18:47:12 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v8]
In-Reply-To: <_DbK4ZSVvMwabc8jXhGrqJD-ox6o9Bvo9or64AKUQ4E=.8bd87542-9eed-456d-8d87-a065da637918@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <nOA8eBHYej8JEaxzqPMjf5Xs6D5xG17gpYkM6cc-G7w=.ccd0421c-7814-449d-a4d5-4176d1148659@github.com>
 <_DbK4ZSVvMwabc8jXhGrqJD-ox6o9Bvo9or64AKUQ4E=.8bd87542-9eed-456d-8d87-a065da637918@github.com>
Message-ID: <MSrGVEdd7FI0S4cgoJtzdTfd4aHEakZgEbotZtAUbYw=.ba2564ef-f401-4ed2-98df-55c9f3db114d@github.com>

On Fri, 6 Sep 2024 18:39:08 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathUtils.java line 33:
> 
>> 31:  *
>> 32:  */
>> 33: public class VectorMathUtils {
> 
> Could the class also be not public as it has only package private methods now?

Please ignore this comment as Paul suggests that the methods in this file should to be public.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1747571110

From liach at openjdk.org  Fri Sep  6 19:05:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 19:05:20 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator
Message-ID: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>

Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.

-------------

Commit messages:
 - 8339683: Simplify class data generation in InvokerBytecodeGenerator

Changes: https://git.openjdk.org/jdk/pull/20896/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20896&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339683
  Stats: 65 lines in 1 file changed: 7 ins; 32 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/20896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20896/head:pull/20896

PR: https://git.openjdk.org/jdk/pull/20896

From swen at openjdk.org  Fri Sep  6 19:33:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 6 Sep 2024 19:33:09 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v9]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <jAKqgnO-ggKWzqa9ZPmRPBfCQKLVkOQst__dvfB1O3g=.a8b1f275-8cfc-4bf1-9c62-093f425a298f@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - java doc
 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/System.java
   #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - ACC_ABSTRACT
 - suggestion from @liach
 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - reuseThreshold -> cacheThreshold
 - Revert "optimize for CompactStrings is off"
   
   This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.
 - optimize for CompactStrings is off
 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - add control flag `reuseThreshold`
 - ... and 6 more: https://git.openjdk.org/jdk/compare/fbe26293...c4737625

-------------

Changes: https://git.openjdk.org/jdk/pull/20675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=08
  Stats: 132 lines in 3 files changed: 83 ins; 2 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From psandoz at openjdk.org  Fri Sep  6 19:55:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 19:55:04 GMT
Subject: RFR: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and
 laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits
In-Reply-To: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
References: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
Message-ID: <LgD8LgcZQYd989fsHzZvIsb7VbfY198_AuLv_8kUiMs=.7a0379c7-f190-454b-95fd-cd9efe62ca00@github.com>

On Fri, 6 Sep 2024 18:31:00 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes an issue where we mistakenly use `Double::doubleToLongBits` in `DoubleXXXVector::withLaneHelper` and `DoubleXXXVector::laneHelper`. We should use the raw bit version instead.
> 
> Please kindly review, thanks very much.

Looks good!

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20895#pullrequestreview-2287057663

From liach at openjdk.org  Fri Sep  6 19:55:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 19:55:38 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
Message-ID: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>

> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Do not try to classdata non-live lambda forms in pre-generation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20896/files
  - new: https://git.openjdk.org/jdk/pull/20896/files/1602657d..4f163cb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20896&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20896&range=00-01

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20896/head:pull/20896

PR: https://git.openjdk.org/jdk/pull/20896

From bchristi at openjdk.org  Fri Sep  6 20:04:42 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 6 Sep 2024 20:04:42 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
Message-ID: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>

>From the bug description:
ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.

Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;

For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).

The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.

I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.

While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

-------------

Commit messages:
 - rearrange reachabilityFence() calls

Changes: https://git.openjdk.org/jdk/pull/20898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20898&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339687
  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20898/head:pull/20898

PR: https://git.openjdk.org/jdk/pull/20898

From redestad at openjdk.org  Fri Sep  6 21:03:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 21:03:04 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
 <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
Message-ID: <_kEFiDQD6SlLztQ3gIUvOtvmlId1IIevZXaJsWiWcCU=.f9dd3a6b-c8f7-48c4-9201-793997bc3354@github.com>

On Fri, 6 Sep 2024 19:55:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not try to classdata non-live lambda forms in pre-generation

Can you explain the semantics of not generating classData when pre-generating LFs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20896#issuecomment-2334802330

From liach at openjdk.org  Fri Sep  6 21:12:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 21:12:03 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
 <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
Message-ID: <XvlX3mqifMjmz5EOCwuDku1YpvK5sqDACH-qPTbp-l4=.126632d4-67ed-4c4d-b37a-13ce56a16e06@github.com>

On Fri, 6 Sep 2024 19:55:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not try to classdata non-live lambda forms in pre-generation

pregen never kept class data, as they never call clinit generation. so this was silently discarded in pregen. The class name and class desc are wrong for pregen but they happen to be never used. new logic generates unused and wrong fieldref in invoker holder, and this update fixes it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20896#issuecomment-2334814119

From sviswanathan at openjdk.org  Fri Sep  6 21:45:15 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Sep 2024 21:45:15 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v3]
In-Reply-To: <2nRoXBr_v8DjlG4wJlWF9OhYMmgpTUDX6VAQnvO3DCY=.596e5e39-c5ba-4d20-b5e0-aa301f7c9d76@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
 <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>
 <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>
 <2nRoXBr_v8DjlG4wJlWF9OhYMmgpTUDX6VAQnvO3DCY=.596e5e39-c5ba-4d20-b5e0-aa301f7c9d76@github.com>
Message-ID: <efbaXAFWJhglfJN3hW6Jb8LpRn_g8_iTQY1sb0bQfaE=.01550ea7-f249-4195-b3dd-9cd9cf87c0e9@github.com>

On Wed, 4 Sep 2024 01:57:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @theRealAph, this implementation is based on Intel libm math library and meets the accuracy requirements. The algorithm is provided in the comments.
>
> @vamsi-parasa  don't hesitate in adding as much and explicit information about the original source from where the algorithm has been picked up, even though the PR explicitly mentions libm. Adding the link to source references is a good practice.

@jatin-bhateja This is based on Intel internal LIBM sources and so there is no public link available.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1747726562

From sviswanathan at openjdk.org  Fri Sep  6 21:45:16 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Sep 2024 21:45:16 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v3]
In-Reply-To: <efbaXAFWJhglfJN3hW6Jb8LpRn_g8_iTQY1sb0bQfaE=.01550ea7-f249-4195-b3dd-9cd9cf87c0e9@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
 <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>
 <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>
 <2nRoXBr_v8DjlG4wJlWF9OhYMmgpTUDX6VAQnvO3DCY=.596e5e39-c5ba-4d20-b5e0-aa301f7c9d76@github.com>
 <efbaXAFWJhglfJN3hW6Jb8LpRn_g8_iTQY1sb0bQfaE=.01550ea7-f249-4195-b3dd-9cd9cf87c0e9@github.com>
Message-ID: <KoJBKorzjlQlf8skof0BOfjBdLB6ic5dMoPVlMP-I7E=.4cae0625-30c6-4d80-8467-e7f528b0862e@github.com>

On Fri, 6 Sep 2024 21:15:07 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> @vamsi-parasa  don't hesitate in adding as much and explicit information about the original source from where the algorithm has been picked up, even though the PR explicitly mentions libm. Adding the link to source references is a good practice.
>
> @jatin-bhateja This is based on Intel internal LIBM sources and so there is no public link available.

> Do you have a copy of this information? Should it be in the commit?

@theRealAph The accuracy of standard (non fast mode) LIBM functions ensures errors of < 1 ulp. LIBM is part of Intel C++ compiler. The documentation can be found here: https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-8/programming-tradeoffs-floating-point-applications.html.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1747742612

From naoto at openjdk.org  Fri Sep  6 21:49:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Sep 2024 21:49:30 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3]
In-Reply-To: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
Message-ID: <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>

> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Strictly conforming to the spec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20893/files
  - new: https://git.openjdk.org/jdk/pull/20893/files/8e711667..5d5c2019

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=01-02

  Stats: 80 lines in 3 files changed: 17 ins; 26 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/20893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20893/head:pull/20893

PR: https://git.openjdk.org/jdk/pull/20893

From naoto at openjdk.org  Fri Sep  6 21:54:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Sep 2024 21:54:09 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3]
In-Reply-To: <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
 <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
Message-ID: <5lj0AD5gQvxIaVZgtRKcEfrA3ar9sS9fSVeH1wX8ls4=.264ea7d7-d841-4a98-80ca-734b960ffb29@github.com>

On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strictly conforming to the spec

Had to modify the fix. According to zic(8):

Names must be in English and are case insensitive.  They appear in several contexts, and include month and weekday names and keywords such as ?maximum?, ?only?, ?Rolling?, and ?Zone?.  A name can be abbreviated by omitting all but an initial prefix; any abbreviation must be unambiguous in context

Thus April can not only either "Apr" or "April", but also "apr", "april", "apri", or "Ap". The fix assumes the source tz files already have unbiguous names.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20893#issuecomment-2334857393

From sviswanathan at openjdk.org  Fri Sep  6 22:08:14 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Sep 2024 22:08:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v8]
In-Reply-To: <nOA8eBHYej8JEaxzqPMjf5Xs6D5xG17gpYkM6cc-G7w=.ccd0421c-7814-449d-a4d5-4176d1148659@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <nOA8eBHYej8JEaxzqPMjf5Xs6D5xG17gpYkM6cc-G7w=.ccd0421c-7814-449d-a4d5-4176d1148659@github.com>
Message-ID: <FNvk2zL3UumXih3lD19jPHJeDDwve94lKYddAcAD69Q=.0d44f156-1c4f-484a-a264-0c1ff69a7683@github.com>

On Fri, 6 Sep 2024 06:43:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Thank you for taking care of all my comments.

/Reviewers 2

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2287215687
PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2334870617

From jlu at openjdk.org  Fri Sep  6 22:19:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Sep 2024 22:19:23 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3]
In-Reply-To: <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
 <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
Message-ID: <zsR-HmD50RnffPzHFotFa5MLeYypwmjrTMgHU-QEeL0=.66b58fdb-d58e-4bdf-9a02-4e335fc4e32f@github.com>

On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strictly conforming to the spec

Marked as reviewed by jlu (Committer).

New fix LGTM.

> Month names may be abbreviated as mentioned previously;
> for example, January can appear as
> .q January ,
> .q JANU
> or
> .q Ja ,
> but not as
> .q j

So I think it's safe to assume unambiguous abbreviations.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2287223428
PR Comment: https://git.openjdk.org/jdk/pull/20893#issuecomment-2334879456

From redestad at openjdk.org  Fri Sep  6 22:22:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Sep 2024 22:22:19 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
 <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
Message-ID: <Z_1oHjj8zovAaAAtH2c6KbxHMeYjxzPx5cBFibdwug8=.1ee3a1bd-a37d-4c4e-9e02-6cca2f9377e5@github.com>

On Fri, 6 Sep 2024 19:55:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not try to classdata non-live lambda forms in pre-generation

Right, for pre-generated forms we don't need any tricks to keep the form and the implementation class alive together as these methods are added to the Holder class. So this is good. 

Maybe we should assert against attempting to add classData fields to a pre-generated LF? 

Which class name is wrong? I don't see it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20896#issuecomment-2334883135

From liach at openjdk.org  Fri Sep  6 22:29:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 22:29:06 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
 <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
Message-ID: <TTtCJcdeZx9opuHiflPq0r_RmZqaW6dr_cXi8Zx97Ss=.eb707974-b352-45f3-b10b-1344e31af496@github.com>

On Fri, 6 Sep 2024 19:55:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not try to classdata non-live lambda forms in pre-generation

For pregen we pass in the Holder class name for ctor parameter name. They then get a Lambdaform$ prefix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20896#issuecomment-2334894454

From smarks at openjdk.org  Sat Sep  7 00:43:08 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 7 Sep 2024 00:43:08 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
Message-ID: <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>

On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
> 
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
> 
> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
> 
> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
> 
> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
> 
> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

test/lib/jdk/test/lib/util/ForceGC.java line 82:

> 80:         PhantomReference<Object> ref = new PhantomReference<>(obj, queue);
> 81:         Reference.reachabilityFence(obj);
> 82:         obj = null;

You're right to question the utility of calling reachabilityFence(obj) after obj has been nulled out. But I'm still questioning the utility of calling RF(obj) at all. We don't care when obj is determined to be unreachable; what we care about is that the GC has done some reference processing. Seems to me we can simplify the above lines to

    PhantomReference<Object> ref = new PhantomReference<>(new Object(), queue);

and get rid of the local variable obj entirely.

test/lib/jdk/test/lib/util/ForceGC.java line 102:

> 100:             }
> 101:         }
> 102:         Reference.reachabilityFence(ref);

I think everything from the creation of ref to the line above needs to enclosed in a try-statement, with the finally-clause including RF(ref).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1747839937
PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1747840429

From smarks at openjdk.org  Sat Sep  7 01:02:08 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 7 Sep 2024 01:02:08 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
Message-ID: <6yn2UGscloAIQ9iyruHzAbL-uSypFtQClnlvS86G-YQ=.4a49fe1f-d22e-4302-a84a-a009236844c6@github.com>

On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
> 
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
> 
> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
> 
> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
> 
> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
> 
> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

I added a couple specific comments on the code that I thought ought to be addressed in this PR.

There is a broader issue with the timeout logic that we should be aware of, however, we might or might not choose to address it in this PR. The main issue is that the caller has requested a particular amount of time as the timeout, and the timeout loop divides by 200ms to determine the maximum number of retries. This _assumes_ that each loop will take 200ms. However, this might not be true, because we don't know how long the booleanSupplier takes, we don't know how long System.gc() takes, and we don't know how long queue.remove() takes. This isn't an idle concern. Somebody might pass in a booleanSupplier that itself has a timeout (say of 1 second) which will cause this method to take about six times longer than expected to time out.

The usual approach for timeout logic is to take the initial System.nanoTime() value and compare subsequent return values of nanoTime() to the timeout duration, and exit the loop if the timeout duration has been exceeded. See the nanoTime() javadoc for an example.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20898#issuecomment-2334978441

From jpai at openjdk.org  Sat Sep  7 04:50:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 7 Sep 2024 04:50:03 GMT
Subject: RFR: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and
 laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits
In-Reply-To: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
References: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
Message-ID: <k8vB49WnWpfRLYx26KCscdKLwXeLvQFn6HQMXrZ0-nk=.fa626dca-552f-4133-8152-fda8057a952a@github.com>

On Fri, 6 Sep 2024 18:31:00 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes an issue where we mistakenly use `Double::doubleToLongBits` in `DoubleXXXVector::withLaneHelper` and `DoubleXXXVector::laneHelper`. We should use the raw bit version instead.
> 
> Please kindly review, thanks very much.

Hello @merykitty, there are several files in this PR with just copyright year updates and no other change. Is that intentional?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20895#issuecomment-2335040747

From qamai at openjdk.org  Sat Sep  7 05:18:07 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 7 Sep 2024 05:18:07 GMT
Subject: RFR: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and
 laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits
In-Reply-To: <LgD8LgcZQYd989fsHzZvIsb7VbfY198_AuLv_8kUiMs=.7a0379c7-f190-454b-95fd-cd9efe62ca00@github.com>
References: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
 <LgD8LgcZQYd989fsHzZvIsb7VbfY198_AuLv_8kUiMs=.7a0379c7-f190-454b-95fd-cd9efe62ca00@github.com>
Message-ID: <I6iL4C72C87UUZ2oXUrPJj1WlRxfu20qi2cKQK6SOl4=.b9771e2b-6ecd-4ed0-8fde-b21a8224ab9c@github.com>

On Fri, 6 Sep 2024 19:52:28 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes an issue where we mistakenly use `Double::doubleToLongBits` in `DoubleXXXVector::withLaneHelper` and `DoubleXXXVector::laneHelper`. We should use the raw bit version instead.
>> 
>> Please kindly review, thanks very much.
>
> Looks good!

@PaulSandoz Thanks for your reviews, I think this patch is trivial so I will merge it.

@jaikiran All the `YYYXXXVector.java` files are generated from `X-VectorBits.java.template`, so if I change some of them all the others will get their copyright year updated as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20895#issuecomment-2335047445

From swen at openjdk.org  Sat Sep  7 07:55:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 7 Sep 2024 07:55:38 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF
Message-ID: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>

PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

-------------

Commit messages:
 - extract to JDKUTF
 - code style
 - optimize ObjectOutputStream#writeUTF
 - optimize DataOutputStream#writeUTF
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/20886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339699
  Stats: 393 lines in 5 files changed: 212 ins; 151 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/20886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20886/head:pull/20886

PR: https://git.openjdk.org/jdk/pull/20886

From swen at openjdk.org  Sat Sep  7 07:55:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 7 Sep 2024 07:55:38 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <nAMoC9VDCkHnirHXuKK7-PojHL47HfLrN3Op_4up5es=.5942ebbf-73ca-4b18-a9af-6ff776df1b84@github.com>

On Fri, 6 Sep 2024 09:58:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

Below are the performance numbers running on a MacBook M1 Pro. Both DataOutputStreamBench::writeUTF and ObjectOutputStream::writeUTF have been significantly improved in various character sets.

## 1.1 Script


git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline
git chekcout 42f47a8979f20457114e7c63d28d66db044b23dd
make test TEST="micro:java.io.DataOutputStreamBench"

# current
git checkout 30786c277bc006db6a55be267673878d7ea8db9b
make test TEST="micro:java.io.DataOutputStreamBench"


## 1.2 Performance Numbers

-# baseline
-Benchmark                                (charType)  Mode  Cnt   Score    Error  Units
-DataOutputStreamBench.dataOutwriteUTF         ascii  avgt   12  13.202 ?  0.238  us/op
-DataOutputStreamBench.dataOutwriteUTF  utf8_2_bytes  avgt   12  16.771 ?  0.145  us/op
-DataOutputStreamBench.dataOutwriteUTF  utf8_3_bytes  avgt   12  48.448 ?  0.112  us/op
-DataOutputStreamBench.dataOutwriteUTF         emoji  avgt   12  53.540 ? 30.963  us/op
-DataOutputStreamBench.objectWriteUTF          ascii  avgt   12   8.800 ?  0.017  us/op
-DataOutputStreamBench.objectWriteUTF   utf8_2_bytes  avgt   12  35.113 ?  0.058  us/op
-DataOutputStreamBench.objectWriteUTF   utf8_3_bytes  avgt   12  36.352 ?  0.152  us/op
-DataOutputStreamBench.objectWriteUTF          emoji  avgt   12  56.454 ?  0.069  us/op

+# current
+Benchmark                                (charType)  Mode  Cnt   Score   Error  Units
+DataOutputStreamBench.dataOutwriteUTF         ascii  avgt   12   5.292 ? 0.040  us/op
+DataOutputStreamBench.dataOutwriteUTF  utf8_2_bytes  avgt   12  11.678 ? 0.105  us/op
+DataOutputStreamBench.dataOutwriteUTF  utf8_3_bytes  avgt   12  27.907 ? 0.048  us/op
+DataOutputStreamBench.dataOutwriteUTF         emoji  avgt   12  49.144 ? 0.176  us/op
+DataOutputStreamBench.objectWriteUTF          ascii  avgt   12   4.693 ? 0.032  us/op
+DataOutputStreamBench.objectWriteUTF   utf8_2_bytes  avgt   12  16.993 ? 0.028  us/op
+DataOutputStreamBench.objectWriteUTF   utf8_3_bytes  avgt   12  23.619 ? 0.115  us/op
+DataOutputStreamBench.objectWriteUTF          emoji  avgt   12  41.335 ? 0.372  us/op


|   | charType | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| DataOutputStreamBench.dataOutwriteUTF | ascii | 13.202 | 5.292 | 149.47% |
| DataOutputStreamBench.dataOutwriteUTF | utf8_2_bytes | 16.771 | 11.678 | 43.61% |
| DataOutputStreamBench.dataOutwriteUTF | utf8_3_bytes | 48.448 | 27.907 | 73.61% |
| DataOutputStreamBench.dataOutwriteUTF | emoji | 53.540 | 49.144 | 8.95% |
| DataOutputStreamBench.objectWriteUTF | ascii | 8.800 | 4.693 | 87.51% |
| DataOutputStreamBench.objectWriteUTF | utf8_2_bytes | 35.113 | 16.993 | 106.63% |
| DataOutputStreamBench.objectWriteUTF | utf8_3_bytes | 36.352 | 23.619 | 53.91% |
| DataOutputStreamBench.objectWriteUTF | emoji | 56.454 | 41.335 | 36.58% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20886#issuecomment-2335108105

From swen at openjdk.org  Sat Sep  7 08:44:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 7 Sep 2024 08:44:43 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v2]
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <XNr-i1BkvWX2UennGFQRxbMn-enihhCvoeKT0v5QrPI=.affb7e71-fa39-4003-814b-e774ea4c814e@github.com>

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20886/files
  - new: https://git.openjdk.org/jdk/pull/20886/files/30786c27..a04b2c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20886/head:pull/20886

PR: https://git.openjdk.org/jdk/pull/20886

From swen at openjdk.org  Sat Sep  7 08:51:25 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 7 Sep 2024 08:51:25 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v3]
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  reduce JDKUTF#utflen codeSize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20886/files
  - new: https://git.openjdk.org/jdk/pull/20886/files/a04b2c34..9744e8a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20886/head:pull/20886

PR: https://git.openjdk.org/jdk/pull/20886

From mdoerr at openjdk.org  Sat Sep  7 13:13:09 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 7 Sep 2024 13:13:09 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v5]
In-Reply-To: <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
Message-ID: <UlWya-cvHothKwRo0_Q_0yNy9xs81tlMHQ9ysQs3HwU=.cc91690c-3760-4484-8ce0-b4a8db55309d@github.com>

On Fri, 6 Sep 2024 17:51:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove PC save/restore on s390

Fun facts (measured on PPC64le fastdbg build which contains some asm asserts):
simple upcall stub: 520 Bytes (regardless of selected GC)
upcall_stub_load_target with G1: 72 Bytes
upcall_stub_load_target with ZGC: 1204 Bytes (more than 2x the upcall stub + the G1 version!)
upcall_stub_load_target with Shenandoah: 1364 Bytes
Great to have the upcall_stub_load_target only once :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2335182768

From jpai at openjdk.org  Sat Sep  7 13:15:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 7 Sep 2024 13:15:04 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <XaEiYNzheaIhDuaVO1GK5zC8YfEyB_84RVBuv4xo3KU=.1df7ab6f-7017-40be-b3af-7c6668458c55@github.com>

On Fri, 6 Sep 2024 16:28:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 478:

> 476:                     long elapsedMillis = Math.max(1,
> 477:                             TimeUnit.NANOSECONDS.toMillis(end - start));
> 478:                     timeoutLeft = timeoutLeft - (int) elapsedMillis;

Hello Aleksei, should this `int` cast take into account potential integer value overflow? In theory (and probably even in practice depending on what the initial timeout value was configured to), the `elapsedMillis`, I think can be a value greater than `Integer.MAX_VALUE`, in which case this cast to `int` can cause unexpected computation of `timeoutLeft`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1748082435

From duke at openjdk.org  Sat Sep  7 14:15:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 7 Sep 2024 14:15:04 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v3]
In-Reply-To: <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>
Message-ID: <5q5hxCU3zIfRflJBEFYliYRGw0Sy2DnHmLIrODqrDkA=.f6c1023a-2427-435a-ba18-835fa571aee3@github.com>

On Sat, 7 Sep 2024 08:51:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce JDKUTF#utflen codeSize

src/java.base/share/classes/java/io/DataOutputStream.java line 382:

> 380:         ByteArray.setUnsignedShort(bytearr, count, utflen);
> 381:         count += 2;
> 382:         str.getBytes(0, countNonZeroAscii, bytearr, count);

Maybe?the?deprecated [`String?::getBytes?(int,?int, byte[],?int)`] method?calls could?be?moved to?a?method in?`JDKUTF` in?order to?avoid?having to?use?overly?broad `@SuppressWarnings("deprecation")`:

@ForceInline
@SuppressWarnings("deprecation")
public static void getBytes(String str, int srcPos, byte[] dst, int dstPos, int length) {
	str.getBytes(srcPos, srcPos + length, dst, dstPos);
}


[`String?::getBytes?(int,?int, byte[],?int)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#getBytes(int,int,byte[],int)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1748098802

From swen at openjdk.org  Sat Sep  7 14:40:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 7 Sep 2024 14:40:05 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v3]
In-Reply-To: <5q5hxCU3zIfRflJBEFYliYRGw0Sy2DnHmLIrODqrDkA=.f6c1023a-2427-435a-ba18-835fa571aee3@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>
 <5q5hxCU3zIfRflJBEFYliYRGw0Sy2DnHmLIrODqrDkA=.f6c1023a-2427-435a-ba18-835fa571aee3@github.com>
Message-ID: <LI7_hKYFkywzcE4YMw9nMXEvdssrISvjDebC54wMusI=.28dee36d-cc65-4b40-9704-7e6045be2c2d@github.com>

On Sat, 7 Sep 2024 14:04:55 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce JDKUTF#utflen codeSize
>
> src/java.base/share/classes/java/io/DataOutputStream.java line 382:
> 
>> 380:         ByteArray.setUnsignedShort(bytearr, count, utflen);
>> 381:         count += 2;
>> 382:         str.getBytes(0, countNonZeroAscii, bytearr, count);
> 
> Maybe?the?deprecated [`String?::getBytes?(int,?int, byte[],?int)`][`String?::getBytes`] method?calls could?be?moved to?a?method in?`JDKUTF` in?order to?avoid?having to?use?overly?broad `@SuppressWarnings("deprecation")`:
> 
> @ForceInline
> @SuppressWarnings("deprecation")
> public static void getBytes(String str, int srcPos, byte[] dst, int dstPos, int length) {
> 	str.getBytes(srcPos, srcPos + length, dst, dstPos);
> }
> 
> 
> [`String?::getBytes`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#getBytes(int,int,byte%5B%5D,int)

Although this will eliminate the warning, JDKUTF provides capabilities that are unrelated to it. What happens if a scenario other than JDKUTF is called?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1748198717

From miiiinju00 at gmail.com  Sat Sep  7 15:36:30 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Sun, 8 Sep 2024 00:36:30 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
Message-ID: <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>

Hi Viktor,

I hope you're doing well. I apologize for reaching out again so soon, but after further reflection, I realized that my previous explanation regarding the issue might have been inaccurate.

In my earlier email, I mentioned that the problem was related to count and signal, but it seems that this isn't the cause of the issue. I wanted to clarify the situation based on the same assumption?that multiple threads (T1 to T10) are waiting in Condition::await() while the queue is full.

Here's a clearer outline of the scenario:

Threads T1 to T10 are waiting on Condition::await() because the queue is full.
T11 calls take() and holds the lock via lock.lockInterruptibly().
T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (As I understand, the wait queue for ReentrantLock and Condition are separate.)
T11 reduces the count and sends a signal, then releases the lock.
T1 receives the signal and moves to the lock queue. Since the ReentrantLock is in fair mode, T12 (which was already waiting) gets priority, and T1 will acquire the lock later.
T12 acquires the lock and successfully enqueues.
Ultimately, while take() is being called, if other threads are queued for the ReentrantLock, the thread that receives the signal may be pushed down in priority in the ReentrantLock queue. This is the situation I suspect might be happening, although I believe it would occur only very rarely.
Once again, I greatly appreciate your patience and willingness to listen to my thoughts, despite my imperfect understanding. Thank you so much for your time and insights.

Best regards,

Kim Minju


> 2024. 9. 7. ?? 1:02, ??? <miiiinju00 at gmail.com> ??:
> 
> Dear Viktor,
> 
> I hope this email finds you well. First and foremost, thank you for providing such a detailed explanation of the AQS issue.
> 
> Based on Archie's suggestion, I've taken the liberty of implementing a custom ArrayBlockingQueue3 class and created a test case that attempts to reproduce the scenario you described. I've particularly focused on the potential "barging" behavior you mentioned.
> 
> Following Archie's recommendation, I've added the following implementation to ArrayBlockingQueue3:
> 
> private final HashSet<Thread> puttingThreads = new HashSet<>();
> 
> public void put(E e) throws InterruptedException {
>     Objects.requireNonNull(e);
>     final ReentrantLock lock = this.lock;
>     lock.lockInterruptibly();
>     final boolean added = puttingThreads.add(Thread.currentThread());
>     try {
>         while (count == items.length) {
>             notFull.await();
>         }
>         enqueue(e);
>     } finally {
>         if (added)
>             puttingThreads.remove(Thread.currentThread());
>         lock.unlock();
>     }
> }
> 
> public boolean isPutting(Thread thread) {
>     final ReentrantLock lock = this.lock;
>     lock.lock();
>     try {
>         return puttingThreads.contains(thread);
>     } finally {
>         lock.unlock();
>     }
> }
> Using this modified implementation, I've written a test case that attempts to simulate the scenario. I've attached the full test code to this email for your reference.
> 
> 
> 
> --------------------------------------------------------
> 
> The issue arises in the brief moment between when the thread performing the take() decreases the count and just before it sends the signal, during which another thread calling put() can acquire the lock via lock.lockInterruptibly(). I understand that the waiting spaces for Condition.await() and the ReentrantLock are separate, which contributes to this subtle timing problem. When a thread is signaled in Condition.await(), it is transferred from the Condition's waiting queue to the lock queue, where it must reacquire the lock before proceeding.
> 
> To better understand the timing of this issue, it may be helpful to review the dequeue method inside the queue.take()method
> 
> private E dequeue() {
>     // assert lock.isHeldByCurrentThread();
>     // assert lock.getHoldCount() == 1;
>     // assert items[takeIndex] != null;
>     final Object[] items = this.items;
>     @SuppressWarnings("unchecked")
>     E e = (E) items[takeIndex];
>     items[takeIndex] = null;
>     if (++takeIndex == items.length) takeIndex = 0;
>     count--;
>     if (itrs != null)
>         itrs.elementDequeued();
>     notFull.signal();
>     return e;
> }
> --------------------------------------------------------
> Test Code
> 
> package org.main;
> 
> import static org.junit.jupiter.api.Assertions.assertEquals;
> 
> import java.util.ArrayList;
> import java.util.List;
> import org.example.ArrayBlockingQueue3;
> import org.junit.jupiter.api.Test;
> 
> class ThreadStarvationTest {
> 
>     @Test
>     void test() throws InterruptedException {
>         // Set the capacity of the queue
>         int CAPACITY = 10;
>         // Create an instance of ArrayBlockingQueue3 with fairness mode enabled
>         ArrayBlockingQueue3<Integer> queue = new ArrayBlockingQueue3<>(CAPACITY, true);
>         
>         // Preload the queue to its capacity
>         int PRELOAD_VALUE = -1;
>         for (int i = 0; i < CAPACITY; i++) {
>             queue.add(PRELOAD_VALUE);
>         }
> 
>         // Create threads that are already waiting to put elements
>         int ALREADY_PUT_COUNT = 10;
>         int ALREADY_PUT_NUMBER = 10;
>         for (int i = 0; i < ALREADY_PUT_COUNT; i++) {
>             Thread thread = new Thread(() -> {
>                 try {
>                     // put() will block because the queue is full
>                     // This thread simulates T2, the thread trying to put an element while the queue is full.
>                     queue.put(ALREADY_PUT_NUMBER);
>                 } catch (InterruptedException e) {
>                     // ignore
>                 }
>             });
>             thread.start();
> 
>             // Wait until the thread is actually trying to put
>             while (!queue.isPutting(thread)) ;
>         }
> 
>         // Give time for all threads to enter waiting state
>         Thread.sleep(2000);
> 
>         // Set up new producer threads
>         final int PRODUCER_PUT_NUMBER = -999;
>         final int PRODUCER_COUNT = 1000;
> 
>         final Runnable producingJob = () -> {
>             try {
>                 // T3
>                 queue.put(PRODUCER_PUT_NUMBER);
>             } catch (InterruptedException e) {
>                 // ignore
>             }
>         };
>         // Thread to start new producer threads when consumption begins
>         Thread produceWhenConsumingThread = new Thread(() -> {
>             for (int i = 0; i < PRODUCER_COUNT; i++) {
>                 Thread thd = new Thread(producingJob);
>                 thd.start();
>             }
>         });
>         
>         ArrayList<Integer> result = new ArrayList<>();
> 
>         // Start new producer threads simultaneously with consumption
>         produceWhenConsumingThread.start();
> 
>         // Consume elements from the queue
>         for (int i = 0; i < CAPACITY + ALREADY_PUT_COUNT; i++) {
>             // Can be T1
>             Integer take = queue.take();
>             result.add(take);
>         }
> 
>         // Expected result
> 
>         List<Integer> expected = new ArrayList<>();
>         // First 10 elements should be -1 (preloaded values)
>         for (int i = 0; i < CAPACITY; i++) {
>             expected.add(PRELOAD_VALUE);
>         }
>         // Next 10 elements should be 10 (from already waiting threads)
>         for (int i = 0; i < ALREADY_PUT_COUNT; i++) {
>             expected.add(ALREADY_PUT_NUMBER);
>         }
> 
>         // Assert that the actual result matches the expected result
>         assertEquals(expected, result);
>     }
> 
> }
> 
> Expected :[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10]
> Actual   :[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 10, 10, 10, 10, -999, -999, 10, -999, -999, 10]
> The test aims to recreate the following sequence:
> 
> The queue is full, and T2 is executing put() and is waiting in Condition.await().
> T1 calls queue.take(), removes an item from the queue, and just before signaling, T1 decreases the count. At this point, the queue is no longer full (count != items.length).
> T3 acquires the lock via lock.lockInterruptibly().
> T1 then sends the Condition.signal(), and T2 is still waiting to acquire the lock via lock.lockInterruptibly().
> T3 successfully enqueues an item because the while (count == items.length) condition is not satisfied. T3 then increases the count again, making the queue full (count == items.length).
> T2 finally acquires the lock via lock.lockInterruptibly(), but since the queue is full again, T2 hits the while(count == items.length) condition and goes back to Condition.await().
> This sequence illustrates a potential race condition where T3 acquires the lock just after T1 decreases the count but before T1 sends the signal. Even though T2 is waiting in Condition.await() and receives the signal, I understand that the waiting spaces for Condition.await() and ReentrantLock are separate. Because of this, I believe that T3 can still acquire the lock while T2 is in await(). As a result, T3 can proceed, enqueue an item, and refill the queue, causing T2, once it acquires the lock, to find the queue full again. This race condition seems possible even with a fair lock due to the subtle timing gap between when T1 lowers the count and when it sends the signal, which would force T2 to re-enter the await() state.
> 
> Since this test involves very subtle timing issues, I found it challenging to consistently reproduce it using only three threads. Therefore, my thought was that threads that had previously called put() and were waiting should be guaranteed to enter before subsequent threads that come in during consumption. I've attempted to design the test with this intention.
> 
> I would be incredibly grateful for your insights on whether this test accurately represents the scenario you described. I'm particularly interested in your opinion on whether it might help identify any unexpected behavior.
> 
> There's a possibility that this situation might not correspond to the unbounded unfairness you mentioned. I'm unsure whether this is the intended implementation or if there might be an issue here. Your expertise on this matter would be invaluable. Because it occurs only in extremely rare and extreme cases.
> 
> If you need any clarification or if you think the test should be modified in any way, please don't hesitate to let me know. I'm more than happy to make any necessary adjustments based on your feedback.
> 
> Thank you once again for your time and patience in helping me understand this complex issue.
> 
> Best regards,
> 
> Kim Minju
> 
> 
>> 2024. 9. 6. ?? 8:47, Viktor Klang <viktor.klang at oracle.com> ??:
>> 
>> Hi Kim,
>> 
>> The recent updated to AQS reacquisition has to do with behavior if for some reason there's an exception thrown (think SOE or OOM, or something like that), so it isn't really applicable in this case.
>> 
>> The queue is full, and T2 is executing put() and is waiting in Condition.await().
>> T1 calls queue.take(), removes an item from the queue, and is about to send a signal()
>> T3 is about to call put() and is just before lock.lockInterruptibly().
>> T1 decreases the count and sends a signal(), indicating that space is available in the queue.
>> T3 acquires the lock via lock.lockInterruptibly(), successfully enqueues an item because the count condition is satisfied, and releases the lock.
>> T2 receives the signal and wakes up, but since T3 already enqueued an item, the count has increased, and T2 must wait again in await().
>> 
>> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge". (tryLock() is documented to allow barging)
>> 
>> Let us know if you can come up with a reproducer which says otherwise. ?
>> 
>> Cheers,
>> ?
>> 
>> 
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>> 
>> From: ??? <miiiinju00 at gmail.com>
>> Sent: Friday, 6 September 2024 04:43
>> To: Viktor Klang <viktor.klang at oracle.com>
>> Cc: Archie Cobbs <archie.cobbs at gmail.com>; Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue
>>  
>> Hi Archie,
>> Thanks to your valuable suggestions, I was able to come up with a much more appropriate test, and I?ve learned a great deal in the process. I truly appreciate your insights! While this approach is clearly a significant improvement over the previous one, I still feel there might be concerns about the atomicity between notFull.await() and the signaling from outside, but I can?t deny that this new approach provides much better guarantees. Your feedback has been incredibly helpful, and I?m very grateful for your time and effort. Thank you again!
>> 
>> 
>> 
>> 
>> Hi Viktor,
>> Thank you for sharing your thoughts, which have given me much to consider. I have a follow-up question regarding the improvements in AQS that you mentioned. Specifically, I?d like to clarify whether these improvements ensure that, in the fair mode of ReentrantLock, threads waiting on a Condition are placed back in the queue without acquiring the lock, or if the signaling thread can now immediately acquire the lock after being signaled.
>> Initially, my concern was that a thread receiving a signal might still face starvation if another thread calls put() and acquires the lock before the signaled thread can do so. Here's an example scenario:
>> The queue is full, and T2 is executing put() and is waiting in Condition.await().
>> T1 calls queue.take(), removes an item from the queue, and is about to send a signal()
>> T3 is about to call put() and is just before lock.lockInterruptibly().
>> T1 decreases the count and sends a signal(), indicating that space is available in the queue.
>> T3 acquires the lock via lock.lockInterruptibly(), successfully enqueues an item because the count condition is satisfied, and releases the lock.
>> T2 receives the signal and wakes up, but since T3 already enqueued an item, the count has increased, and T2 must wait again in await().
>> It seems to me that this scenario could occur regardless of whether ReentrantLock is in fair mode or not. Has the improvement in AQS addressed this type of contention scenario to prevent such starvation issues, or is this still a possible outcome?
>> Your insights into "unbounded unfairness" have also provided me with a lot of food for thought, and I?m grateful for the opportunity to reflect on these issues. 
>> In your view, would the thread contention scenario I?ve described fall under the category of unbounded unfairness, or would it be considered an acceptable level of contention?
>> 
>> Once again, thank you for all the knowledge and understanding I've gained through your feedback. I'm truly grateful for your time and expertise.
>> 
>> 
>> Best regards,
>> Kim Minju
>> 
>> 
>> 2024? 9? 6? (?) ?? 4:52, Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>?? ??:
>> Archie,
>> 
>> I should've been more specific?Condition-as-implemented-by-ReentrantLock (in fair mode) provides stronger (for some definition of stronger) semantics that the Condition interface specifies.
>> 
>> Since it's related, I've recently integrated a hardening of AQS and AQLS reacquisition logic in await().
>> 
>> Given what you presented earlier about the detection of "producer parked" it's likely that the conclusion is that ABQ works as expected.
>> 
>> Cheers,
>> ?
>> 
>> 
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>> From: Archie Cobbs <archie.cobbs at gmail.com <mailto:archie.cobbs at gmail.com>>
>> Sent: Thursday, 5 September 2024 21:23
>> To: Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
>> Cc: ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>>; Daniel FUCHS <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>>; 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: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue
>>  
>> Apologies in advance if I'm misunderstanding anything...
>> 
>> On Thu, Sep 5, 2024 at 2:05?PM Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>> wrote:
>>  Thread state polling aside, for as long as Condition::await() is allowed to spuriously wake, FIFO just cannot be "guaranteed".
>>  
>> What about this statement in the Javadoc for ReentrantLock.newCondition():
>> 
>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
>> 
>> So what you're saying is that a spurious wakeup on a Condition is not the same thing as a spurious signal() on a Condition; if it were, then the above statement would apply and FIFO ordering would be preserved.
>> 
>> Of course, a spurious wakeup would not find the condition being waited on satisfied unless there was a big coincidence. So an ordering violation that actually mattered should be exceedingly rare.
>> 
>> Anyway, this does seem to be a glitch in how things are supposed to work. That is: there can be no guaranteed ordering for Condition waiters when there can be spurious wakeups.
>> 
>> Maybe this corner case should be documented. Or better yet, fix the bug by requiring Condition to "filter out" spurious wakeups if preserving FIFO ordering (it should be possible).
>> 
>> -Archie
>> 
>> --
>> Archie L. Cobbs
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240908/4fb6eb35/attachment-0001.htm>

From archie.cobbs at gmail.com  Sat Sep  7 18:34:22 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sat, 7 Sep 2024 13:34:22 -0500
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
Message-ID: <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>

Hi Kim,

On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com> wrote:

> Here's a clearer outline of the scenario:
>
>    - Threads T1 to T10 are waiting on Condition::await() because the
>    queue is full.
>    - T11 calls take() and holds the lock via lock.lockInterruptibly().
>    - T12 calls queue.put() and enters the wait queue for
>    lock.lockInterruptibly(). (As I understand, the wait queue for
>    ReentrantLock and Condition are separate.)
>    - T11 reduces the count and sends a signal, then releases the lock.
>    - T1 receives the signal and moves to the lock queue. Since the
>    ReentrantLock is in fair mode, T12 (which was already waiting) gets
>    priority, and T1 will acquire the lock later.
>    - T12 acquires the lock and successfully enqueues.
>
> From one reading of the Javadoc, your step #5 ("T12 gets priority") is not
supposed to happen that way. Instead, one of T1 through T10 should be
guaranteed to acquire the lock.

Here it is again (from ReentrantLock.newCondition()):

The ordering of lock reacquisition for threads returning from waiting
> methods is the same as for threads initially acquiring the lock, which is
> in the default case not specified, but for *fair* locks favors those
> threads that have been waiting the longest.


But part of the problem here is that this documentation is ambiguous.

The ambiguity is: are ALL threads trying to acquire the lock, whether on an
initial attempt or after a condition wakeup, ordered for fairness together
in one big pool? ? In this case step #5 can't happen. Call this
Interpretation A.

Or is this merely saying that threads waiting on a condition reacquire the
lock based on when they started waiting on the condition, but there are no
ordering guarantees between those threads and any other unrelated threads
trying to acquire the lock? ? In this case step #5 can happen. Call this
Interpretation B.

So I think we first need to clarify which interpretation is correct here, A
or B.

On that point, Victor said this:

I've re-read ReentrantLock and AQS, and from my understanding on the logic
> the Condition's place in the wait queue should be maintained, which means
> that T3 shouldn't be able to "barge".


So it sounds like Victor is confirming interpretation A. Victor do you
agree?

If so, then it seems like we need to do two things:

1. File a Jira ticket to clarify the Javadoc, e.g. to say something like
this:

The ordering of lock reacquisition for threads returning from waiting
> methods is the same as for threads initially acquiring the lock, which is
> in the default case not specified, but for *fair* locks favors those
> threads that have been waiting the longest. *In the latter case, the
> ordering consideration includes all threads attempting to acquire the lock,
> regardless of whether or not they were previously blocked on the condition.*
>

2. Understand why Kim's updated test case is still failing (it must be
either a bug in the test or a bug in ArrayBlockingQueue).

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240907/6b75d53a/attachment.htm>

From dev at anthonyv.be  Sat Sep  7 19:03:33 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Sat, 07 Sep 2024 19:03:33 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>

September 2, 2024 at 10:36 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> Hi Anthony,

Hi Viktor

> Thank you for your patience, I needed some time to experiment and think about your feedback.
> 
> >* how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?
> 
> If looking at the past to inform extrapolation into the future, then the trend is going in the direction of improving over time.
> 
> >Gatherers.identity()
> 
> I still need some time to experiment with this, as there are some implications.
> For instance, if you do: **Steam.of(1).gather(Gatherers.identity()) **you'd want that gatherer to be dropped since it is a no-op, but you can't really do that without breaking the contract of Stream.gather, as that operation should "consume" the original Stream reference and return a new one (to preserve stream building linearity), so you'd still need to create a new ReferencePipeline instance which is a copy of the current one, and mark the previous as consumed)?in essence Stream.gather(identity) wouldn't be a no-op.
> 
> There are some other, performance-related, things I'll need to verify as well before coming to any conclusion on this.
> 
> >Gatherers.concat(Stream<T> stream)

The non-reusability is intentional here, being a drop-in replacement for `Stream::concat`.
(In what follows, assume the ellipses are method references, and the pipelines are nicely formatted and perfectly readable.)

The idea is to be able to write pipelines of the form:
var list = foo.filter(...).map(...).flatMap(...).concat(bar).map(...).filter(...).gather(...).toList();

Currently you have to write such pipelines as:
var list = Stream.concat(foo.filter(...).map(...).flatMap(...), bar).map(...).filter(...).gather(...).toList();

or:
var head = foo.filter(...).map(...).flatMap(...);
var concatenated = Stream.concat(head, bar);
var list = concatenated.map(...).filter(...).gather(...).toList();

But now you could write them as follows and retain a single, fluent pipeline:
var list = foo.filter(...).map(...).flatMap(...).gather(concat(bar)).map(...).filter(...).gather(...).toList();

My argument for including it would be that the above use case is common enough. `Stream::concat` could then also reference it in its Javadoc as an alternative.

> Creating such a Gatherer means that it is not reusable. You'd need to have a Supplier<Stream<T>>. Otherwise this happens:
> 
> jshell> ? ? public static?<T> Gatherer<T, ?, T> **concat**(Stream<T>**newStream**) {
> ?? ...> ? ? ? ? return?Gatherer.of(
> ?? ...> ? ? ? ? ? ? ? ? Gatherer.Integrator.ofGreedy((_, **e**, **d**) -> d.push(e)),
> ?? ...> ? ? ? ? ? ? ? ? (_, **d**) -> newStream.sequential().allMatch(d::push)
> ?? ...> ? ? ? ? );
> ?? ...> ? ? }
> ?? ...>?
> |? created method concat(Stream<T>)
> 
> jshell> var **inject**?= concat(Stream.of(1,2))
> inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000db898 at 1068e947]
> 
> jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
> |? Exception java.lang.IllegalStateException: stream has already been operated upon or closed
> |? ? ? ? at AbstractPipeline.evaluate (AbstractPipeline.java:260)
> |? ? ? ? at ReferencePipeline.allMatch (ReferencePipeline.java:677)
> |? ? ? ? at lambda$concat$1 (#4:4)
> |? ? ? ? at Gatherers$Composite.lambda$impl$3 (Gatherers.java:611)
> |? ? ? ? at GathererOp$GatherSink.end (GathererOp.java:181)
> |? ? ? ? at AbstractPipeline.copyInto (AbstractPipeline.java:571)
> |? ? ? ? at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
> |? ? ? ? at AbstractPipeline.evaluate (AbstractPipeline.java:636)
> |? ? ? ? at AbstractPipeline.evaluateToArrayNode (AbstractPipeline.java:291)
> |? ? ? ? at ReferencePipeline.toArray (ReferencePipeline.java:656)
> |? ? ? ? at ReferencePipeline.toArray (ReferencePipeline.java:662)
> |? ? ? ? at ReferencePipeline.toList (ReferencePipeline.java:667)
> |? ? ? ? at (#6:1)
> 
> That being said, given how little code it takes to implement something like that, I am not sure it warrants inclusion:
> jshell> ? ? public static?<T> Gatherer<T, ?, T> **concat**(Supplier<?extends?Stream<T>> **newStream**) {
> ?? ...> ? ? ? ? return?Gatherer.of(
> ?? ...> ? ? ? ? ? ? ? ? Gatherer.Integrator.ofGreedy((**_**, **e**, **d**) -> d.push(e)),
> ?? ...> ? ? ? ? ? ? ? ? (**_**, **d**) -> newStream.get().sequential().allMatch(d::push)
> ?? ...> ? ? ? ? );
> ?? ...> ? ? }
> |? created method concat(Supplier<? extends Stream<T>>)
> 
> jshell> var **inject**?= concat(() -> Stream.of(1,2))
> inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000d9c70 at 1a052a00]
> 
> jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
> $1 ==> [0, 1, 2, 1, 2]
> 
> Cheers,
> 
> ?
> 
> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle

Kind regards,
Anthony

> ????????????????????????????????????????????????????????????????
> 
> **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:**?Monday, 19 August 2024 20:37
> **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:**?Re: [External] : Re: Stream Gatherers (JEP 473) feedback
> ?
> 
> August 15, 2024 at 1:27 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > Hi Anthony,
> 
> Hi Viktor
> 
> > Thanks for the input?it's much appreciated!
> 
> >
> 
> > Introducing yet another, user-facing, type parameter to get slightly improved type inference is unfortunately for me a too high of a price to pay. Ideally, type inference/unification will be improved over time making this issue go away without impacting any signatures.
> 
> My arguments would be:
> 
> * the type parameter enables using subtypes of Downstream, e.g. `Gatherer::integrator` could return an `Integrator<A, T, R, SpecialDownstream<R>>`
> 
> * the type parameter improves type inference
> 
> * the type parameter would increase usability. In my experience, nearly all Gatherers are created through the factory methods in Gatherer. And thanks to the improved type inference, I assert that all factory method invocations would work without any type arguments at all. Nowadays type inference is so good that I found it remarkable how often (relatively speaking) I need to provide type arguments with Gatherers, compared to other generic APIs. A substantial amount of Java developers has probably never even had to provide type arguments before, so being able to eliminate their need from the Gatherers API as well seems like a considerable advantage to me
> 
> * how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?
> 
> > I'm warming up to the idea of shipping a Gatherers.identity(), and before that happens I would like to see more use-cases where having such a thing would provide a real edge. I can come up with a bunch of synthetic scenarios where it's a win, but it's always better to see app logic numbers.
> 
> To summarize previous mails, my arguments are:
> 
> * it's a common Gatherer. Gatherers of the form `Gatherer<T, ?, T>` will likely have a degenerate case that is the identity. Some actual factory methods are `append(T... elements)` and `concat(Stream<T> stream)`, `prepend(T... elements)`, and `withInterpolationAt(Set<Instant> instants)`.
> 
> * optimization: if a Stream pipeline only contains compositions of `Gatherer.identity()`, the Gatherers can be eliminated entirely from the pipeline and characteristics can be propagated. So for example `list.stream().gather(withInterpolationAt(aSetThatHappensToBeEmpty)).count()` would be optimized to `list.stream().count()` and return instantly. Note that while a homemade implementation could optimize its `andThen` implementation, it wouldn't be able to optimize `Gatherer::andThen` and `Stream::gather`.
> 
> * API consistency: there's `Function.identity()`, so why not `Gatherers.identity()` (or `Gatherer.identity()`)? Actually I'd argue this method is more useful for Gatherers, since for Functions, this is often written as `o -> o` instead. For Gatherers there's no alternative like that.
> 
> On a final note, in case it hasn't been done yet, I'd like to propose `Gatherers.concat(Stream<T> stream)`. The current `Stream::concat` doesn't allow fluent/readable concatenation of multiple streams.
> 
> > Getting rid of the rawtypes in Value could be done, at any point since it isn't exposed to user code. I'll keep this in mind for any upcoming maintenance ?
> 
> >
> 
> > Keep the feedback coming ?
> 
> >
> 
> > Cheers,
> 
> >
> 
> > ?
> 
> Kind regards,
> 
> Anthony
> 
> > **Viktor Klang**
> 
> > Software Architect, Java Platform Group
> 
> >
> 
> > Oracle
> 
> >
> 
> > ????????????????????????????????????????????????????????????????
> 
> >
> 
> > **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > **Sent:** Tuesday, 13 August 2024 18:32
> 
> > **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
> 
> > ?
> 
> >
> 
> > Hi Viktor
> 
> >
> 
> > Your previous response inspired me to experiment some more with Gatherers
> 
> >
> 
> > As a result I'd like to make a couple propositions:
> 
> >
> 
> > * add an additional type parameter.
> 
> >
> 
> > ? After doing so, type inference no longer needs any assistance:
> 
> >
> 
> > ? `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
> 
> >
> 
> > * add an identity Gatherer with an optimized `andThen` implementation
> 
> >
> 
> > ? as well as an optimization in the default implementation of `Gatherer::andThen`
> 
> >
> 
> > * eliminate the use of raw types in `Gatherers.Value`
> 
> >
> 
> > Code that implements these propositions is in this gist: https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVct8oxUqg$
> 
> >
> 
> > Kind regards,
> 
> >
> 
> > Anthony
> 
> >
> 
> > July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > >
> 
> >
> 
> > > Hi Anthony,
> 
> >
> 
> > >
> 
> >
> 
> > > >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> >
> 
> > >
> 
> >
> 
> > > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> >
> 
> > >
> 
> >
> 
> > > Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
> 
> >
> 
> > >
> 
> >
> 
> > > >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> >
> 
> > >
> 
> >
> 
> > > Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
> 
> >
> 
> > >
> 
> >
> 
> > > >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> >
> 
> > >
> 
> >
> 
> > > Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVdv0LXetA$
> 
> >
> 
> > >
> 
> >
> 
> > > Cheers,
> 
> >
> 
> > >
> 
> >
> 
> > > ?
> 
> >
> 
> > >
> 
> >
> 
> > > **Viktor Klang**
> 
> >
> 
> > > Software Architect, Java Platform Group
> 
> >
> 
> > >
> 
> >
> 
> > > Oracle
> 
> >
> 
> > >
> 
> >
> 
> > > ????????????????????????????????????????????????????????????????
> 
> >
> 
> > >
> 
> >
> 
> > > **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> >
> 
> > > **Sent:**?Tuesday, 30 July 2024 17:20
> 
> >
> 
> > > **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> >
> 
> > > **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> 
> >
> 
> > > ?
> 
> >
> 
> > >
> 
> >
> 
> > > July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Hi Anthony,
> 
> >
> 
> > >
> 
> >
> 
> > > Hi Viktor
> 
> >
> 
> > >
> 
> >
> 
> > > > Thank you for your patience, and for providing feedback, it is always much appreciated.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > >When writing factory methods for Gatherers, there's sometimes a
> 
> >
> 
> > >
> 
> >
> 
> > > > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> >
> 
> > >
> 
> >
> 
> > > > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> >
> 
> > >
> 
> >
> 
> > > > to recognize and eliminate it from the pipeline. One idea is to add
> 
> >
> 
> > >
> 
> >
> 
> > > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> >
> 
> > >
> 
> >
> 
> > > > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
> 
> >
> 
> > >
> 
> >
> 
> > > > but rather adding it in case it was deemed necessary.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Do you have a concrete use-case (code) that you could share?
> 
> >
> 
> > >
> 
> >
> 
> > > The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> >
> 
> > >
> 
> >
> 
> > > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> >
> 
> > >
> 
> >
> 
> > > > >Sometimes a factory method returns a Gatherer that only works correctly
> 
> >
> 
> > >
> 
> >
> 
> > > > if the upstream has certain characteristics, for example
> 
> >
> 
> > >
> 
> >
> 
> > > > Spliterator.SORTED or Spliterator.DISTINCT.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Do you have a concrete use-case (code) that you could share?
> 
> >
> 
> > >
> 
> >
> 
> > > All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
> 
> >
> 
> > >
> 
> >
> 
> > > > >One idea is to add methods
> 
> >
> 
> > >
> 
> >
> 
> > > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> >
> 
> > >
> 
> >
> 
> > > > implementation would be able to recognize and eliminate these from the
> 
> >
> 
> > >
> 
> >
> 
> > > > pipeline if the upstream already has these characteristics. That way
> 
> >
> 
> > >
> 
> >
> 
> > > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> >
> 
> > >
> 
> >
> 
> > > > idea is to provide a Gatherer with a way to inspect the upstream
> 
> >
> 
> > >
> 
> >
> 
> > > > characteristics. If the upstream is missing the required
> 
> >
> 
> > >
> 
> >
> 
> > > > characteristic(s), it could then throw an IllegalStateException.
> 
> >
> 
> > >
> 
> >
> 
> > > I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
> 
> >
> 
> > >
> 
> >
> 
> > > > For a rather long time Gatherer had characteristics, however,
> 
> >
> 
> > >
> 
> >
> 
> > > > what I noticed is that given composition of Gatherers what ended up happening
> 
> >
> 
> > >
> 
> >
> 
> > > > almost always was that the combination of characteristics added overhead and devolved into the empty set
> 
> >
> 
> > >
> 
> >
> 
> > > > real fast.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
> 
> >
> 
> > >
> 
> >
> 
> > > > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
> 
> >
> 
> > >
> 
> >
> 
> > > In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
> 
> >
> 
> > >
> 
> >
> 
> > > That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> >
> 
> > >
> 
> >
> 
> > > > >The returns clause of Gatherer.Integrator::integrate just states "true
> 
> >
> 
> > >
> 
> >
> 
> > > > if subsequent integration is desired, false if not". In particular, it
> 
> >
> 
> > >
> 
> >
> 
> > > > doesn't document the behavior I'm observing, that returning false also
> 
> >
> 
> > >
> 
> >
> 
> > > > causes downstream to reject any further output elements.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
> 
> >
> 
> > >
> 
> >
> 
> > > I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$? ), but this is indeed already fixed in JDK 23-ea.
> 
> >
> 
> > >
> 
> >
> 
> > > This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> >
> 
> > >
> 
> >
> 
> > > > Cheers,
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > ?
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > **Viktor Klang**
> 
> >
> 
> > >
> 
> >
> 
> > > > Software Architect, Java Platform Group
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Oracle
> 
> >
> 
> > >
> 
> >
> 
> > > Kind regards,
> 
> >
> 
> > >
> 
> >
> 
> > > Anthony
> 
> >
> 
> > >
> 
> >
> 
> > > > ????????????????????????????????????????????????????????????????
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> >
> 
> > >
> 
> >
> 
> > > > **Sent:** Saturday, 27 July 2024 08:57
> 
> >
> 
> > >
> 
> >
> 
> > > > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> >
> 
> > >
> 
> >
> 
> > > > **Subject:** Stream Gatherers (JEP 473) feedback
> 
> >
> 
> > >
> 
> >
> 
> > > > ?
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > When writing factory methods for Gatherers, there's sometimes a
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > to recognize and eliminate it from the pipeline. One idea is to add
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Sometimes a factory method returns a Gatherer that only works correctly
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > if the upstream has certain characteristics, for example
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > implementation would be able to recognize and eliminate these from the
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > pipeline if the upstream already has these characteristics. That way
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > idea is to provide a Gatherer with a way to inspect the upstream
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > characteristics. If the upstream is missing the required
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > characteristic(s), it could then throw an IllegalStateException.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > The returns clause of Gatherer.Integrator::integrate just states "true
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > if subsequent integration is desired, false if not". In particular, it
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > doesn't document the behavior I'm observing, that returning false also
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > causes downstream to reject any further output elements.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > In the Implementation Requirements section of Gatherer, rephrasing
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > "Outputs and state later in the input sequence will be discarded if
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > processing an earlier partition short-circuits." to something like the
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > following would be clearer to me: "As soon as any partition
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > short-circuits, the whole Gatherer short-circuits. The state of other
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > partitions is discarded, i.e. there are no further invocations of the
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > combiner. The finisher is invoked with the short-circuiting partition's
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > state." I wouldn't mention discarding of outputs, since that's implied
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > by the act of short-circuiting.
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
> 
> > > > Anthony
> 
> >
> 
> > >
> 
> >
> 
> > > >
> 
> >
> 
> > >
> 
> >
>

From duke at openjdk.org  Sat Sep  7 20:39:39 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 7 Sep 2024 20:39:39 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
 - Removed redundant code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/df35072c..b48fb7a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=05-06

  Stats: 13 lines in 1 file changed: 0 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From miiiinju00 at gmail.com  Sun Sep  8 00:46:17 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Sun, 8 Sep 2024 09:46:17 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
Message-ID: <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>

Hi Arhice,



First of all, I want to apologize if I may not have explained things clearly since English is not my first language. I?m really sorry about that.



Even so, I deeply appreciate your response and taking the time to reply.



First, I would like to confirm whether my understanding is correct.

From what I know, ReentrantLock is based on AQS, and internally, threads are queued by being linked as Node.

When ReentrantLock.newCondition is called, a ConditionObject is created. When Condition::await is called, the thread waits based on a ConditionNode, and the AQS head is replaced with AQS::signalNext, allowing the lock to be released. At this point, I understand that the node disappears from the AQS queue and starts waiting within the ConditionNode of the ConditionObject.

As a result, I understand that the waiting places for ReentrantLock and Condition are different.

To summarize, when Condition::await() is called, the node that was previously waiting in AQS receives the lock, disappears from the AQS queue, and starts waiting within the ConditionNode of the ConditionObject.

Additionally, from what I understand, in Condition::doSignal, the first ConditionNode is removed, and then AQS::enqueue adds it to the tail of AQS.

public class ConditionObject implements Condition, java.io.Serializable {

private void doSignal(ConditionNode first, boolean all) {
    while (first != null) {
        ConditionNode next = first.nextWaiter;
        if ((firstWaiter = next) == null)
            lastWaiter = null;
        if ((first.getAndUnsetStatus(COND) & COND) != 0) {
            enqueue(first);
            if (!all)
                break;
        }
        first = next;
    }
}

When enqueue is called:

public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer

    /*
     * Tail of the wait queue. After initialization, modified only via casTail.
     */
    private transient volatile Node tail;

	 final void enqueue(Node node) {
	    if (node != null) {
	        for (;;) {
	            Node t = tail;
	            node.setPrevRelaxed(t);        // avoid unnecessary fence
	            if (t == null)                 // initialize
	                tryInitializeHead();
	            else if (casTail(t, node)) {
	                t.next = node;
	                if (t.status < 0)          // wake up to clean link
	                    LockSupport.unpark(node.waiter);
	                break;
	            }
	        }
	    }
}

From my understanding, this attaches the node to the tail of AQS.

To elaborate further on the situation:

Threads T1 to T10 are waiting on Condition::await() because the queue is full.

(At this point, T1 to T10 are linked through ConditionNode.) [The AQS queue is empty, while ConditionNode holds T1 to T10.]

T11 calls take() and holds the lock via lock.lockInterruptibly().

(Since no threads are waiting in the AQS queue, T11 will acquire the lock immediately.)

[Now, AQS holds T11 at its head, and ConditionNode holds T1 to T10.]

T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (Since T11 is holding the lock with take(), T12 will be queued behind it in AQS.)

[Now, AQS holds T11 and T12, while ConditionNode holds T1 to T10.]

T11 reduces the count and sends a signal, then releases the lock.

T1 receives the signal and moves to the lock queue. Since ReentrantLock is in fair mode,

(When T11 sends the signal, T1, the first thread linked in ConditionNode, will be enqueued via AQS::enqueue. Now, AQS holds T11, T12, and T1, while ConditionNode holds T2 to T10.)

T11 releases the lock and wakes up T12.

[Now, AQS holds T12 and T1, while ConditionNode holds T2 to T10.]

T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without being blocked by while(count==length).

T12 releases the lock, and the next node in AQS is unparked.

[Now, AQS holds T1, while ConditionNode holds T2 to T10.]

T1, having reacquired the lock after Condition::await(), fails to exit the while loop and waits again.

[Now, ConditionNode holds T1 and T2 to T10.]



This is how I currently understand the situation.

If there are any mistakes in my understanding, I would greatly appreciate your clarification.

Best Regards,

 Kim Minju


> 2024. 9. 8. ?? 3:34, Archie Cobbs <archie.cobbs at gmail.com> ??:
> 
> Hi Kim,
> 
> On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>> Here's a clearer outline of the scenario:
>> 
>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (As I understand, the wait queue for ReentrantLock and Condition are separate.)
>> T11 reduces the count and sends a signal, then releases the lock.
>> T1 receives the signal and moves to the lock queue. Since the ReentrantLock is in fair mode, T12 (which was already waiting) gets priority, and T1 will acquire the lock later.
>> T12 acquires the lock and successfully enqueues.
> From one reading of the Javadoc, your step #5 ("T12 gets priority") is not supposed to happen that way. Instead, one of T1 through T10 should be guaranteed to acquire the lock.
> 
> Here it is again (from ReentrantLock.newCondition()):
> 
>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
> 
> 
> But part of the problem here is that this documentation is ambiguous.
> 
> The ambiguity is: are ALL threads trying to acquire the lock, whether on an initial attempt or after a condition wakeup, ordered for fairness together in one big pool? ? In this case step #5 can't happen. Call this Interpretation A.
> 
> Or is this merely saying that threads waiting on a condition reacquire the lock based on when they started waiting on the condition, but there are no ordering guarantees between those threads and any other unrelated threads trying to acquire the lock? ? In this case step #5 can happen. Call this Interpretation B.
> 
> So I think we first need to clarify which interpretation is correct here, A or B.
> 
> On that point, Victor said this:
> 
>> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge".
> 
> 
> So it sounds like Victor is confirming interpretation A. Victor do you agree?
> 
> If so, then it seems like we need to do two things:
> 
> 1. File a Jira ticket to clarify the Javadoc, e.g. to say something like this:
> 
>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest. In the latter case, the ordering consideration includes all threads attempting to acquire the lock, regardless of whether or not they were previously blocked on the condition.
> 
> 
> 2. Understand why Kim's updated test case is still failing (it must be either a bug in the test or a bug in ArrayBlockingQueue).
> 
> -Archie
> 
> --
> Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240908/a87a21ca/attachment-0001.htm>

From miiiinju00 at gmail.com  Sun Sep  8 00:46:17 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Sun, 8 Sep 2024 09:46:17 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
Message-ID: <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>

Hi Arhice,



First of all, I want to apologize if I may not have explained things clearly since English is not my first language. I?m really sorry about that.



Even so, I deeply appreciate your response and taking the time to reply.



First, I would like to confirm whether my understanding is correct.

From what I know, ReentrantLock is based on AQS, and internally, threads are queued by being linked as Node.

When ReentrantLock.newCondition is called, a ConditionObject is created. When Condition::await is called, the thread waits based on a ConditionNode, and the AQS head is replaced with AQS::signalNext, allowing the lock to be released. At this point, I understand that the node disappears from the AQS queue and starts waiting within the ConditionNode of the ConditionObject.

As a result, I understand that the waiting places for ReentrantLock and Condition are different.

To summarize, when Condition::await() is called, the node that was previously waiting in AQS receives the lock, disappears from the AQS queue, and starts waiting within the ConditionNode of the ConditionObject.

Additionally, from what I understand, in Condition::doSignal, the first ConditionNode is removed, and then AQS::enqueue adds it to the tail of AQS.

public class ConditionObject implements Condition, java.io.Serializable {

private void doSignal(ConditionNode first, boolean all) {
    while (first != null) {
        ConditionNode next = first.nextWaiter;
        if ((firstWaiter = next) == null)
            lastWaiter = null;
        if ((first.getAndUnsetStatus(COND) & COND) != 0) {
            enqueue(first);
            if (!all)
                break;
        }
        first = next;
    }
}

When enqueue is called:

public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer

    /*
     * Tail of the wait queue. After initialization, modified only via casTail.
     */
    private transient volatile Node tail;

	 final void enqueue(Node node) {
	    if (node != null) {
	        for (;;) {
	            Node t = tail;
	            node.setPrevRelaxed(t);        // avoid unnecessary fence
	            if (t == null)                 // initialize
	                tryInitializeHead();
	            else if (casTail(t, node)) {
	                t.next = node;
	                if (t.status < 0)          // wake up to clean link
	                    LockSupport.unpark(node.waiter);
	                break;
	            }
	        }
	    }
}

From my understanding, this attaches the node to the tail of AQS.

To elaborate further on the situation:

Threads T1 to T10 are waiting on Condition::await() because the queue is full.

(At this point, T1 to T10 are linked through ConditionNode.) [The AQS queue is empty, while ConditionNode holds T1 to T10.]

T11 calls take() and holds the lock via lock.lockInterruptibly().

(Since no threads are waiting in the AQS queue, T11 will acquire the lock immediately.)

[Now, AQS holds T11 at its head, and ConditionNode holds T1 to T10.]

T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (Since T11 is holding the lock with take(), T12 will be queued behind it in AQS.)

[Now, AQS holds T11 and T12, while ConditionNode holds T1 to T10.]

T11 reduces the count and sends a signal, then releases the lock.

T1 receives the signal and moves to the lock queue. Since ReentrantLock is in fair mode,

(When T11 sends the signal, T1, the first thread linked in ConditionNode, will be enqueued via AQS::enqueue. Now, AQS holds T11, T12, and T1, while ConditionNode holds T2 to T10.)

T11 releases the lock and wakes up T12.

[Now, AQS holds T12 and T1, while ConditionNode holds T2 to T10.]

T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without being blocked by while(count==length).

T12 releases the lock, and the next node in AQS is unparked.

[Now, AQS holds T1, while ConditionNode holds T2 to T10.]

T1, having reacquired the lock after Condition::await(), fails to exit the while loop and waits again.

[Now, ConditionNode holds T1 and T2 to T10.]



This is how I currently understand the situation.

If there are any mistakes in my understanding, I would greatly appreciate your clarification.

Best Regards,

 Kim Minju


> 2024. 9. 8. ?? 3:34, Archie Cobbs <archie.cobbs at gmail.com> ??:
> 
> Hi Kim,
> 
> On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>> Here's a clearer outline of the scenario:
>> 
>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (As I understand, the wait queue for ReentrantLock and Condition are separate.)
>> T11 reduces the count and sends a signal, then releases the lock.
>> T1 receives the signal and moves to the lock queue. Since the ReentrantLock is in fair mode, T12 (which was already waiting) gets priority, and T1 will acquire the lock later.
>> T12 acquires the lock and successfully enqueues.
> From one reading of the Javadoc, your step #5 ("T12 gets priority") is not supposed to happen that way. Instead, one of T1 through T10 should be guaranteed to acquire the lock.
> 
> Here it is again (from ReentrantLock.newCondition()):
> 
>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
> 
> 
> But part of the problem here is that this documentation is ambiguous.
> 
> The ambiguity is: are ALL threads trying to acquire the lock, whether on an initial attempt or after a condition wakeup, ordered for fairness together in one big pool? ? In this case step #5 can't happen. Call this Interpretation A.
> 
> Or is this merely saying that threads waiting on a condition reacquire the lock based on when they started waiting on the condition, but there are no ordering guarantees between those threads and any other unrelated threads trying to acquire the lock? ? In this case step #5 can happen. Call this Interpretation B.
> 
> So I think we first need to clarify which interpretation is correct here, A or B.
> 
> On that point, Victor said this:
> 
>> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge".
> 
> 
> So it sounds like Victor is confirming interpretation A. Victor do you agree?
> 
> If so, then it seems like we need to do two things:
> 
> 1. File a Jira ticket to clarify the Javadoc, e.g. to say something like this:
> 
>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest. In the latter case, the ordering consideration includes all threads attempting to acquire the lock, regardless of whether or not they were previously blocked on the condition.
> 
> 
> 2. Understand why Kim's updated test case is still failing (it must be either a bug in the test or a bug in ArrayBlockingQueue).
> 
> -Archie
> 
> --
> Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240908/a87a21ca/attachment-0002.htm>

From duke at openjdk.org  Sun Sep  8 04:08:05 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 8 Sep 2024 04:08:05 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v9]
In-Reply-To: <jAKqgnO-ggKWzqa9ZPmRPBfCQKLVkOQst__dvfB1O3g=.a8b1f275-8cfc-4bf1-9c62-093f425a298f@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <jAKqgnO-ggKWzqa9ZPmRPBfCQKLVkOQst__dvfB1O3g=.a8b1f275-8cfc-4bf1-9c62-093f425a298f@github.com>
Message-ID: <dITH2bL5BYgbiWPVxLkWqZZVrzLx_Nh1LBFdYCvPke4=.53c8a789-d4d8-4295-bac4-5e6cd89c97b3@github.com>

On Fri, 6 Sep 2024 19:33:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - java doc
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/System.java
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - ACC_ABSTRACT
>  - suggestion from @liach
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - reuseThreshold -> cacheThreshold
>  - Revert "optimize for CompactStrings is off"
>    
>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.
>  - optimize for CompactStrings is off
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - add control flag `reuseThreshold`
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/fbe26293...c4737625

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 465:

> 463:      * Get the Coder of String, which is used by StringConcatFactory to calculate the initCoder of constants
> 464:      */
> 465:     byte stringCoder(String str);

Maybe move?this after?`JavaLangAccess?::stringInitCoder()` like?it?was?before?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1749063955

From swen at openjdk.org  Sun Sep  8 05:01:53 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 8 Sep 2024 05:01:53 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v10]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <Hu7tk4MvGO5PD8cldutRIZ5Op1GfnR_E8cTF5o22BOs=.23bd8d6f-6eb5-46c1-b370-318139dd3aeb@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @ExE-Boss 's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/c4737625..711e96d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From swen at openjdk.org  Sun Sep  8 08:36:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 8 Sep 2024 08:36:31 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat
Message-ID: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>

The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.

These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.

These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into str_factory_more_simple_concat_202408
 - Merge remote-tracking branch 'upstream/master' into str_factory_more_simple_concat_202408
 - refactor simple concat

Changes: https://git.openjdk.org/jdk/pull/20726/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339704
  Stats: 330 lines in 4 files changed: 229 ins; 88 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From redestad at openjdk.org  Sun Sep  8 13:21:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Sep 2024 13:21:41 GMT
Subject: RFR: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases
Message-ID: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>

This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.

-------------

Commit messages:
 - Add withFlag(int) to DFB for consistency
 - Avoid loading AccessFlag by providing overrides

Changes: https://git.openjdk.org/jdk/pull/20904/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20904&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339710
  Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20904.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20904/head:pull/20904

PR: https://git.openjdk.org/jdk/pull/20904

From redestad at openjdk.org  Sun Sep  8 13:34:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Sep 2024 13:34:09 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <TCOE5PqhKOgQx-Se93mk7kNae6NDHw9Q1tFlo81uGQ0=.98ee7e83-68a2-49a8-85d0-91fc0edaf7c3@github.com>

On Tue, 27 Aug 2024 10:09:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

src/java.base/share/classes/java/lang/StringConcatHelper.java line 731:

> 729:     @ForceInline
> 730:     static String concat(String prefix, float value, String suffix) {
> 731:         if (prefix == null) prefix = "null";

Since we'll never bind in `null` values all these `prefix == null` are likely redundant unless we expose them to users. Which we probably shouldn't. It's a good thing this PR actually removes some shared secrets rather than adding new ones.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 518:

> 516:             mh = MethodHandles.insertArguments(mh, 2, suffix);
> 517:             return MethodHandles.insertArguments(mh, 0, prefix);
> 518:         } else if (paramCount == 2 && constants[1] == null) {

All `constants` are non-null (see `parseRecipe`)
Suggestion:

        } else if (paramCount == 2 && constants[1].isEmpty()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1749234619
PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1749233891

From liach at openjdk.org  Sun Sep  8 14:17:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 8 Sep 2024 14:17:03 GMT
Subject: RFR: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases
In-Reply-To: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
References: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
Message-ID: <TlK6jOVxrHcSzMDFOlxzxAQSsLb8iwMuTzQW_Dq3XKk=.1e7848b5-43f7-4764-ab39-e0ff3ce23f4d@github.com>

On Sun, 8 Sep 2024 13:17:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.

Do you think we need a parallel declaration in `DirectMethodBuilder`? Though that one won't be used in early bootstrap.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20904#issuecomment-2336702765

From archie.cobbs at gmail.com  Sun Sep  8 14:39:00 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 8 Sep 2024 09:39:00 -0500
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
Message-ID: <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>

Hi Kim,

Thanks for the details.

So to summarize:

   - Kim is saying that "Interpretation B" is how it actually works.
   - Viktor is saying that "Interpretation A" is how it actually works.

Do I have that right?

-Archie

P.S. Viktor: my apologies for misspelling your name before


On Sat, Sep 7, 2024 at 8:04?PM ??? <miiiinju00 at gmail.com> wrote:

> Hi Arhice,
>
>
> First of all, I want to apologize if I may not have explained things
> clearly since English is not my first language. I?m really sorry about that.
>
>
> Even so, I deeply appreciate your response and taking the time to reply.
>
>
> First, I would like to confirm whether my understanding is correct.
>
> From what I know, ReentrantLock is based on AQS, and internally, threads
> are queued by being linked as Node.
>
> When ReentrantLock.newCondition is called, a ConditionObject is created.
> When Condition::await is called, the thread waits based on a ConditionNode,
> and the AQS head is replaced with AQS::signalNext, allowing the lock to
> be released. At this point, I understand that the node disappears from the
> AQS queue and starts waiting within the ConditionNode of the
> ConditionObject.
>
> As a result, I understand that the waiting places for ReentrantLock and
> Condition are different.
>
> To summarize, when Condition::await() is called, the node that was
> previously waiting in AQS receives the lock, disappears from the AQS queue,
> and starts waiting within the ConditionNode of the ConditionObject.
>
> Additionally, from what I understand, in Condition::doSignal, the first
> ConditionNode is removed, and then AQS::enqueue adds it to the tail of AQS
> .
>
> public class ConditionObject implements Condition, java.io.Serializable {
>
> private void doSignal(ConditionNode first, boolean all) {
>     while (first != null) {
>         ConditionNode next = first.nextWaiter;
>         if ((firstWaiter = next) == null)
>             lastWaiter = null;
>         if ((first.getAndUnsetStatus(COND) & COND) != 0) {
>             enqueue(first);
>             if (!all)
>                 break;
>         }
>         first = next;
>     }
> }
>
>
> When enqueue is called:
>
> public abstract class AbstractQueuedSynchronizer
>     extends AbstractOwnableSynchronizer
>
>     /*
>      * Tail of the wait queue. After initialization, modified only via casTail.
>      */
>     private transient volatile Node tail;
>
> 	 final void enqueue(Node node) {
> 	    if (node != null) {
> 	        for (;;) {
> 	            Node t = tail;
> 	            node.setPrevRelaxed(t);        // avoid unnecessary fence
> 	            if (t == null)                 // initialize
> 	                tryInitializeHead();
> 	            else if (casTail(t, node)) {
> 	                t.next = node;
> 	                if (t.status < 0)          // wake up to clean link
> 	                    LockSupport.unpark(node.waiter);
> 	                break;
> 	            }
> 	        }
> 	    }
> }
>
>
> From my understanding, this attaches the node to the tail of AQS.
>
> To elaborate further on the situation:
>
>    1.
>
>    Threads T1 to T10 are waiting on Condition::await() because the queue
>    is full.
>
>    (At this point, T1 to T10 are linked through ConditionNode.) [The AQS queue
>    is empty, while ConditionNode holds T1 to T10.]
>    2.
>
>    T11 calls take() and holds the lock via lock.lockInterruptibly().
>
>    (Since no threads are waiting in the AQS queue, T11 will acquire the
>    lock immediately.)
>
>    [Now, AQS holds T11 at its head, and ConditionNode holds T1 to T10.]
>    3.
>
>    T12 calls queue.put() and enters the wait queue for
>    lock.lockInterruptibly(). (Since T11 is holding the lock with take(),
>    T12 will be queued behind it in AQS.)
>
>    [Now, AQS holds T11 and T12, while ConditionNode holds T1 to T10.]
>    4.
>
>    T11 reduces the count and sends a signal, then releases the lock.
>    5.
>
>    T1 receives the signal and moves to the lock queue. Since ReentrantLock is
>    in fair mode,
>
>    (When T11 sends the signal, T1, the first thread linked in
>    ConditionNode, will be enqueued via AQS::enqueue. Now, AQS holds T11,
>    T12, and T1, while ConditionNode holds T2 to T10.)
>    6.
>
>    T11 releases the lock and wakes up T12.
>
>    [Now, AQS holds T12 and T1, while ConditionNode holds T2 to T10.]
>    7.
>
>    T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without
>    being blocked by while(count==length).
>    8.
>
>    T12 releases the lock, and the next node in AQS is unparked.
>
>    [Now, AQS holds T1, while ConditionNode holds T2 to T10.]
>    9.
>
>    T1, having reacquired the lock after Condition::await(), fails to exit
>    the while loop and waits again.
>
>    [Now, ConditionNode holds T1 and T2 to T10.]
>
>
> This is how I currently understand the situation.
>
> If there are any mistakes in my understanding, I would greatly appreciate
> your clarification.
>
> Best Regards,
>
>  Kim Minju
>
> 2024. 9. 8. ?? 3:34, Archie Cobbs <archie.cobbs at gmail.com> ??:
>
> Hi Kim,
>
> On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com> wrote:
>
>> Here's a clearer outline of the scenario:
>>
>>    - Threads T1 to T10 are waiting on Condition::await() because the
>>    queue is full.
>>    - T11 calls take() and holds the lock via lock.lockInterruptibly().
>>    - T12 calls queue.put() and enters the wait queue for
>>    lock.lockInterruptibly(). (As I understand, the wait queue for
>>    ReentrantLock and Condition are separate.)
>>    - T11 reduces the count and sends a signal, then releases the lock.
>>    - T1 receives the signal and moves to the lock queue. Since the
>>    ReentrantLock is in fair mode, T12 (which was already waiting) gets
>>    priority, and T1 will acquire the lock later.
>>    - T12 acquires the lock and successfully enqueues.
>>
>> From one reading of the Javadoc, your step #5 ("T12 gets priority") is
> not supposed to happen that way. Instead, one of T1 through T10 should be
> guaranteed to acquire the lock.
>
> Here it is again (from ReentrantLock.newCondition()):
>
> The ordering of lock reacquisition for threads returning from waiting
>> methods is the same as for threads initially acquiring the lock, which is
>> in the default case not specified, but for *fair* locks favors those
>> threads that have been waiting the longest.
>
>
> But part of the problem here is that this documentation is ambiguous.
>
> The ambiguity is: are ALL threads trying to acquire the lock, whether on
> an initial attempt or after a condition wakeup, ordered for fairness
> together in one big pool? ? In this case step #5 can't happen. Call this
> Interpretation A.
>
> Or is this merely saying that threads waiting on a condition reacquire the
> lock based on when they started waiting on the condition, but there are no
> ordering guarantees between those threads and any other unrelated threads
> trying to acquire the lock? ? In this case step #5 can happen. Call this
> Interpretation B.
>
> So I think we first need to clarify which interpretation is correct here,
> A or B.
>
> On that point, Victor said this:
>
> I've re-read ReentrantLock and AQS, and from my understanding on the logic
>> the Condition's place in the wait queue should be maintained, which means
>> that T3 shouldn't be able to "barge".
>
>
> So it sounds like Victor is confirming interpretation A. Victor do you
> agree?
>
> If so, then it seems like we need to do two things:
>
> 1. File a Jira ticket to clarify the Javadoc, e.g. to say something like
> this:
>
> The ordering of lock reacquisition for threads returning from waiting
>> methods is the same as for threads initially acquiring the lock, which is
>> in the default case not specified, but for *fair* locks favors those
>> threads that have been waiting the longest. *In the latter case, the
>> ordering consideration includes all threads attempting to acquire the lock,
>> regardless of whether or not they were previously blocked on the condition.*
>>
>
> 2. Understand why Kim's updated test case is still failing (it must be
> either a bug in the test or a bug in ArrayBlockingQueue).
>
> -Archie
>
> --
> Archie L. Cobbs
>
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240908/ce9ea481/attachment-0001.htm>

From swen at openjdk.org  Sun Sep  8 14:39:25 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 8 Sep 2024 14:39:25 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v2]
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <YRp2OZSoq2QDVbdpbxI6-fwCaMv6RBRJFcirM9EqK1A=.a2c91dce-7561-4df4-a163-d12694077c48@github.com>

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20726/files
  - new: https://git.openjdk.org/jdk/pull/20726/files/a0bf70fa..5025729d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From swen at openjdk.org  Sun Sep  8 14:47:08 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 8 Sep 2024 14:47:08 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v2]
In-Reply-To: <TCOE5PqhKOgQx-Se93mk7kNae6NDHw9Q1tFlo81uGQ0=.98ee7e83-68a2-49a8-85d0-91fc0edaf7c3@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <TCOE5PqhKOgQx-Se93mk7kNae6NDHw9Q1tFlo81uGQ0=.98ee7e83-68a2-49a8-85d0-91fc0edaf7c3@github.com>
Message-ID: <slFOI2sHX7qoL55uXDjNnPjXylA-q_LMCAMuW5Ortuk=.6c6fb8ea-f7c0-4dfe-8910-8515e3190c01@github.com>

On Sun, 8 Sep 2024 13:31:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>>   
>>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 731:
> 
>> 729:     @ForceInline
>> 730:     static String concat(String prefix, float value, String suffix) {
>> 731:         if (prefix == null) prefix = "null";
> 
> Since we'll never bind in `null` values all these `prefix == null` are likely redundant unless we expose them to users. Which we probably shouldn't. It's a good thing this PR actually removes some shared secrets rather than adding new ones.

String concatenation is required in many places in java.lang. These static concat methods will be used instead of "+", so null value processing is added. This is also the motivation for using static concat methods instead of Concat1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1749256205

From eirbjo at openjdk.org  Sun Sep  8 14:57:38 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 8 Sep 2024 14:57:38 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
Message-ID: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>

Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.

The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.

In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.

Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.

Testing:

The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.

The `ZipFileOpen` benchmark seems neutral to this change.

-------------

Commit messages:
 - Do not include the END header when reading the CEN section

Changes: https://git.openjdk.org/jdk/pull/20905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339711
  Stats: 13 lines in 2 files changed: 2 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20905/head:pull/20905

PR: https://git.openjdk.org/jdk/pull/20905

From viktor.klang at oracle.com  Sun Sep  8 15:20:25 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sun, 8 Sep 2024 15:20:25 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
Message-ID: <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>

>The non-reusability is intentional here, being a drop-in replacement for `Stream::concat`.

Gatherers are designed to be reusable, Streams not. So having a Gatherer which isn't reusable would be a bit of a non-starter I'm afraid. Or perhaps I misunderstood?

Personally, when I want to concat multiple streams of the same type I do:

Stream.of(foo, bar).flatMap(identity).filter(?).map(?).toList();


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Anthony Vanelverdinghe <dev at anthonyv.be>
Sent: Saturday, 7 September 2024 21:03
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Stream Gatherers (JEP 473) feedback

September 2, 2024 at 10:36 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> Hi Anthony,

Hi Viktor

> Thank you for your patience, I needed some time to experiment and think about your feedback.
>
> >* how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?
>
> If looking at the past to inform extrapolation into the future, then the trend is going in the direction of improving over time.
>
> >Gatherers.identity()
>
> I still need some time to experiment with this, as there are some implications.
> For instance, if you do: **Steam.of(1).gather(Gatherers.identity()) **you'd want that gatherer to be dropped since it is a no-op, but you can't really do that without breaking the contract of Stream.gather, as that operation should "consume" the original Stream reference and return a new one (to preserve stream building linearity), so you'd still need to create a new ReferencePipeline instance which is a copy of the current one, and mark the previous as consumed)?in essence Stream.gather(identity) wouldn't be a no-op.
>
> There are some other, performance-related, things I'll need to verify as well before coming to any conclusion on this.
>
> >Gatherers.concat(Stream<T> stream)

The non-reusability is intentional here, being a drop-in replacement for `Stream::concat`.
(In what follows, assume the ellipses are method references, and the pipelines are nicely formatted and perfectly readable.)

The idea is to be able to write pipelines of the form:
var list = foo.filter(...).map(...).flatMap(...).concat(bar).map(...).filter(...).gather(...).toList();

Currently you have to write such pipelines as:
var list = Stream.concat(foo.filter(...).map(...).flatMap(...), bar).map(...).filter(...).gather(...).toList();

or:
var head = foo.filter(...).map(...).flatMap(...);
var concatenated = Stream.concat(head, bar);
var list = concatenated.map(...).filter(...).gather(...).toList();

But now you could write them as follows and retain a single, fluent pipeline:
var list = foo.filter(...).map(...).flatMap(...).gather(concat(bar)).map(...).filter(...).gather(...).toList();

My argument for including it would be that the above use case is common enough. `Stream::concat` could then also reference it in its Javadoc as an alternative.

> Creating such a Gatherer means that it is not reusable. You'd need to have a Supplier<Stream<T>>. Otherwise this happens:
>
> jshell>     public static <T> Gatherer<T, ?, T> **concat**(Stream<T>**newStream**) {
>    ...>         return Gatherer.of(
>    ...>                 Gatherer.Integrator.ofGreedy((_, **e**, **d**) -> d.push(e)),
>    ...>                 (_, **d**) -> newStream.sequential().allMatch(d::push)
>    ...>         );
>    ...>     }
>    ...>
> |  created method concat(Stream<T>)
>
> jshell> var **inject** = concat(Stream.of(1,2))
> inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000db898 at 1068e947]
>
> jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
> |  Exception java.lang.IllegalStateException: stream has already been operated upon or closed
> |        at AbstractPipeline.evaluate (AbstractPipeline.java:260)
> |        at ReferencePipeline.allMatch (ReferencePipeline.java:677)
> |        at lambda$concat$1 (#4:4)
> |        at Gatherers$Composite.lambda$impl$3 (Gatherers.java:611)
> |        at GathererOp$GatherSink.end (GathererOp.java:181)
> |        at AbstractPipeline.copyInto (AbstractPipeline.java:571)
> |        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
> |        at AbstractPipeline.evaluate (AbstractPipeline.java:636)
> |        at AbstractPipeline.evaluateToArrayNode (AbstractPipeline.java:291)
> |        at ReferencePipeline.toArray (ReferencePipeline.java:656)
> |        at ReferencePipeline.toArray (ReferencePipeline.java:662)
> |        at ReferencePipeline.toList (ReferencePipeline.java:667)
> |        at (#6:1)
>
> That being said, given how little code it takes to implement something like that, I am not sure it warrants inclusion:
> jshell>     public static <T> Gatherer<T, ?, T> **concat**(Supplier<?extends Stream<T>> **newStream**) {
>    ...>         return Gatherer.of(
>    ...>                 Gatherer.Integrator.ofGreedy((**_**, **e**, **d**) -> d.push(e)),
>    ...>                 (**_**, **d**) -> newStream.get().sequential().allMatch(d::push)
>    ...>         );
>    ...>     }
> |  created method concat(Supplier<? extends Stream<T>>)
>
> jshell> var **inject** = concat(() -> Stream.of(1,2))
> inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000d9c70 at 1a052a00]
>
> jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
> $1 ==> [0, 1, 2, 1, 2]
>
> Cheers,
>
> ?
>
> **Viktor Klang**
> Software Architect, Java Platform Group
>
> Oracle

Kind regards,
Anthony

> ????????????????????????????????????????????????????????????????
>
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Monday, 19 August 2024 20:37
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** Re: [External] : Re: Stream Gatherers (JEP 473) feedback
>
>
> August 15, 2024 at 1:27 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > Hi Anthony,
>
> Hi Viktor
>
> > Thanks for the input?it's much appreciated!
>
> >
>
> > Introducing yet another, user-facing, type parameter to get slightly improved type inference is unfortunately for me a too high of a price to pay. Ideally, type inference/unification will be improved over time making this issue go away without impacting any signatures.
>
> My arguments would be:
>
> * the type parameter enables using subtypes of Downstream, e.g. `Gatherer::integrator` could return an `Integrator<A, T, R, SpecialDownstream<R>>`
>
> * the type parameter improves type inference
>
> * the type parameter would increase usability. In my experience, nearly all Gatherers are created through the factory methods in Gatherer. And thanks to the improved type inference, I assert that all factory method invocations would work without any type arguments at all. Nowadays type inference is so good that I found it remarkable how often (relatively speaking) I need to provide type arguments with Gatherers, compared to other generic APIs. A substantial amount of Java developers has probably never even had to provide type arguments before, so being able to eliminate their need from the Gatherers API as well seems like a considerable advantage to me
>
> * how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?
>
> > I'm warming up to the idea of shipping a Gatherers.identity(), and before that happens I would like to see more use-cases where having such a thing would provide a real edge. I can come up with a bunch of synthetic scenarios where it's a win, but it's always better to see app logic numbers.
>
> To summarize previous mails, my arguments are:
>
> * it's a common Gatherer. Gatherers of the form `Gatherer<T, ?, T>` will likely have a degenerate case that is the identity. Some actual factory methods are `append(T... elements)` and `concat(Stream<T> stream)`, `prepend(T... elements)`, and `withInterpolationAt(Set<Instant> instants)`.
>
> * optimization: if a Stream pipeline only contains compositions of `Gatherer.identity()`, the Gatherers can be eliminated entirely from the pipeline and characteristics can be propagated. So for example `list.stream().gather(withInterpolationAt(aSetThatHappensToBeEmpty)).count()` would be optimized to `list.stream().count()` and return instantly. Note that while a homemade implementation could optimize its `andThen` implementation, it wouldn't be able to optimize `Gatherer::andThen` and `Stream::gather`.
>
> * API consistency: there's `Function.identity()`, so why not `Gatherers.identity()` (or `Gatherer.identity()`)? Actually I'd argue this method is more useful for Gatherers, since for Functions, this is often written as `o -> o` instead. For Gatherers there's no alternative like that.
>
> On a final note, in case it hasn't been done yet, I'd like to propose `Gatherers.concat(Stream<T> stream)`. The current `Stream::concat` doesn't allow fluent/readable concatenation of multiple streams.
>
> > Getting rid of the rawtypes in Value could be done, at any point since it isn't exposed to user code. I'll keep this in mind for any upcoming maintenance ?
>
> >
>
> > Keep the feedback coming ?
>
> >
>
> > Cheers,
>
> >
>
> > ?
>
> Kind regards,
>
> Anthony
>
> > **Viktor Klang**
>
> > Software Architect, Java Platform Group
>
> >
>
> > Oracle
>
> >
>
> > ????????????????????????????????????????????????????????????????
>
> >
>
> > **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
>
> > **Sent:** Tuesday, 13 August 2024 18:32
>
> > **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> > **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
> >
>
> >
>
> > Hi Viktor
>
> >
>
> > Your previous response inspired me to experiment some more with Gatherers
>
> >
>
> > As a result I'd like to make a couple propositions:
>
> >
>
> > * add an additional type parameter.
>
> >
>
> >   After doing so, type inference no longer needs any assistance:
>
> >
>
> >   `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
>
> >
>
> > * add an identity Gatherer with an optimized `andThen` implementation
>
> >
>
> >   as well as an optimization in the default implementation of `Gatherer::andThen`
>
> >
>
> > * eliminate the use of raw types in `Gatherers.Value`
>
> >
>
> > Code that implements these propositions is in this gist: https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVct8oxUqg$
>
> >
>
> > Kind regards,
>
> >
>
> > Anthony
>
> >
>
> > July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > >
>
> >
>
> > > Hi Anthony,
>
> >
>
> > >
>
> >
>
> > > >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
>
> >
>
> > >
>
> >
>
> > > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
>
> >
>
> > >
>
> >
>
> > > Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
>
> >
>
> > >
>
> >
>
> > > >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
>
> >
>
> > >
>
> >
>
> > > Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
>
> >
>
> > >
>
> >
>
> > > >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
>
> >
>
> > >
>
> >
>
> > > Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVdv0LXetA$
>
> >
>
> > >
>
> >
>
> > > Cheers,
>
> >
>
> > >
>
> >
>
> > > ?
>
> >
>
> > >
>
> >
>
> > > **Viktor Klang**
>
> >
>
> > > Software Architect, Java Platform Group
>
> >
>
> > >
>
> >
>
> > > Oracle
>
> >
>
> > >
>
> >
>
> > > ????????????????????????????????????????????????????????????????
>
> >
>
> > >
>
> >
>
> > > **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
>
> >
>
> > > **Sent:** Tuesday, 30 July 2024 17:20
>
> >
>
> > > **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> >
>
> > > **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Hi Anthony,
>
> >
>
> > >
>
> >
>
> > > Hi Viktor
>
> >
>
> > >
>
> >
>
> > > > Thank you for your patience, and for providing feedback, it is always much appreciated.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > >When writing factory methods for Gatherers, there's sometimes a
>
> >
>
> > >
>
> >
>
> > > > degenerate case that requires returning a no-op Gatherer. So I'd like a
>
> >
>
> > >
>
> >
>
> > > > way to mark a no-op Gatherer as such, allowing the Stream implementation
>
> >
>
> > >
>
> >
>
> > > > to recognize and eliminate it from the pipeline. One idea is to add
>
> >
>
> > >
>
> >
>
> > > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
>
> >
>
> > >
>
> >
>
> > > > Another is to add Gatherers.identity(), analogous to Function.identity().
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
>
> >
>
> > >
>
> >
>
> > > > but rather adding it in case it was deemed necessary.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Do you have a concrete use-case (code) that you could share?
>
> >
>
> > >
>
> >
>
> > > The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
>
> >
>
> > >
>
> >
>
> > > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
>
> >
>
> > >
>
> >
>
> > > > >Sometimes a factory method returns a Gatherer that only works correctly
>
> >
>
> > >
>
> >
>
> > > > if the upstream has certain characteristics, for example
>
> >
>
> > >
>
> >
>
> > > > Spliterator.SORTED or Spliterator.DISTINCT.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Do you have a concrete use-case (code) that you could share?
>
> >
>
> > >
>
> >
>
> > > All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
>
> >
>
> > >
>
> >
>
> > > > >One idea is to add methods
>
> >
>
> > >
>
> >
>
> > > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
>
> >
>
> > >
>
> >
>
> > > > implementation would be able to recognize and eliminate these from the
>
> >
>
> > >
>
> >
>
> > > > pipeline if the upstream already has these characteristics. That way
>
> >
>
> > >
>
> >
>
> > > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
>
> >
>
> > >
>
> >
>
> > > > idea is to provide a Gatherer with a way to inspect the upstream
>
> >
>
> > >
>
> >
>
> > > > characteristics. If the upstream is missing the required
>
> >
>
> > >
>
> >
>
> > > > characteristic(s), it could then throw an IllegalStateException.
>
> >
>
> > >
>
> >
>
> > > I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
>
> >
>
> > >
>
> >
>
> > > > For a rather long time Gatherer had characteristics, however,
>
> >
>
> > >
>
> >
>
> > > > what I noticed is that given composition of Gatherers what ended up happening
>
> >
>
> > >
>
> >
>
> > > > almost always was that the combination of characteristics added overhead and devolved into the empty set
>
> >
>
> > >
>
> >
>
> > > > real fast.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
>
> >
>
> > >
>
> >
>
> > > > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
>
> >
>
> > >
>
> >
>
> > > In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
>
> >
>
> > >
>
> >
>
> > > That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
>
> >
>
> > >
>
> >
>
> > > > >The returns clause of Gatherer.Integrator::integrate just states "true
>
> >
>
> > >
>
> >
>
> > > > if subsequent integration is desired, false if not". In particular, it
>
> >
>
> > >
>
> >
>
> > > > doesn't document the behavior I'm observing, that returning false also
>
> >
>
> > >
>
> >
>
> > > > causes downstream to reject any further output elements.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
>
> >
>
> > >
>
> >
>
> > > I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$  ), but this is indeed already fixed in JDK 23-ea.
>
> >
>
> > >
>
> >
>
> > > This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
>
> >
>
> > >
>
> >
>
> > > > Cheers,
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > ?
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > **Viktor Klang**
>
> >
>
> > >
>
> >
>
> > > > Software Architect, Java Platform Group
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Oracle
>
> >
>
> > >
>
> >
>
> > > Kind regards,
>
> >
>
> > >
>
> >
>
> > > Anthony
>
> >
>
> > >
>
> >
>
> > > > ????????????????????????????????????????????????????????????????
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
>
> >
>
> > >
>
> >
>
> > > > **Sent:** Saturday, 27 July 2024 08:57
>
> >
>
> > >
>
> >
>
> > > > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> >
>
> > >
>
> >
>
> > > > **Subject:** Stream Gatherers (JEP 473) feedback
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > When writing factory methods for Gatherers, there's sometimes a
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > degenerate case that requires returning a no-op Gatherer. So I'd like a
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > way to mark a no-op Gatherer as such, allowing the Stream implementation
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > to recognize and eliminate it from the pipeline. One idea is to add
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Another is to add Gatherers.identity(), analogous to Function.identity().
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Sometimes a factory method returns a Gatherer that only works correctly
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > if the upstream has certain characteristics, for example
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > implementation would be able to recognize and eliminate these from the
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > pipeline if the upstream already has these characteristics. That way
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > idea is to provide a Gatherer with a way to inspect the upstream
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > characteristics. If the upstream is missing the required
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > characteristic(s), it could then throw an IllegalStateException.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > The returns clause of Gatherer.Integrator::integrate just states "true
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > if subsequent integration is desired, false if not". In particular, it
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > doesn't document the behavior I'm observing, that returning false also
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > causes downstream to reject any further output elements.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > In the Implementation Requirements section of Gatherer, rephrasing
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > "Outputs and state later in the input sequence will be discarded if
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > processing an earlier partition short-circuits." to something like the
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > following would be clearer to me: "As soon as any partition
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > short-circuits, the whole Gatherer short-circuits. The state of other
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > partitions is discarded, i.e. there are no further invocations of the
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > combiner. The finisher is invoked with the short-circuiting partition's
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > state." I wouldn't mention discarding of outputs, since that's implied
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > by the act of short-circuiting.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Anthony
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240908/6c0a7b94/attachment-0001.htm>

From redestad at openjdk.org  Sun Sep  8 16:40:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Sep 2024 16:40:03 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v2]
In-Reply-To: <slFOI2sHX7qoL55uXDjNnPjXylA-q_LMCAMuW5Ortuk=.6c6fb8ea-f7c0-4dfe-8910-8515e3190c01@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <TCOE5PqhKOgQx-Se93mk7kNae6NDHw9Q1tFlo81uGQ0=.98ee7e83-68a2-49a8-85d0-91fc0edaf7c3@github.com>
 <slFOI2sHX7qoL55uXDjNnPjXylA-q_LMCAMuW5Ortuk=.6c6fb8ea-f7c0-4dfe-8910-8515e3190c01@github.com>
Message-ID: <w3LViqepvmgpsQMfN4dT8NqviAgZapy00mXAX_hOwMg=.f86a5131-b0cd-4a74-ad42-6f0acf9282a0@github.com>

On Sun, 8 Sep 2024 14:44:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 731:
>> 
>>> 729:     @ForceInline
>>> 730:     static String concat(String prefix, float value, String suffix) {
>>> 731:         if (prefix == null) prefix = "null";
>> 
>> Since we'll never bind in `null` values all these `prefix == null` are likely redundant unless we expose them to users. Which we probably shouldn't. It's a good thing this PR actually removes some shared secrets rather than adding new ones.
>
> String concatenation is required in many places in java.lang. These static concat methods will be used instead of "+", so null value processing is added. This is also the motivation for using static concat methods instead of Concat1.

I don't think replacing a lot of concatenations in java.base with `SCH.concat` is very appealing and needs to be motivated by a substantial performance advantage. And for the places where it's motivated we can make sure to sanitize and handle `null` arguments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1749288882

From redestad at openjdk.org  Sun Sep  8 16:48:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Sep 2024 16:48:36 GMT
Subject: RFR: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases [v2]
In-Reply-To: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
References: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
Message-ID: <WB5X3XqABp1V9dfk8BI_GOSMFoqdPlKwENRIbd6PLy4=.6272dce1-1f32-42bd-8a27-c3ba309f90ce@github.com>

> This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add DMB.withFlags for consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20904/files
  - new: https://git.openjdk.org/jdk/pull/20904/files/fc90e83d..df6e8e89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20904&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20904&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20904.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20904/head:pull/20904

PR: https://git.openjdk.org/jdk/pull/20904

From redestad at openjdk.org  Sun Sep  8 16:48:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Sep 2024 16:48:36 GMT
Subject: RFR: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases
In-Reply-To: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
References: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
Message-ID: <ksVhcbbN6Wpon_QEYgUF7g_I3OnspfnXYKCejJALCQQ=.184ab198-4d05-4751-bac7-6f351700d8e6@github.com>

On Sun, 8 Sep 2024 13:17:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.

Added `DirectMethodBuilder::withFlags` too, for consistency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20904#issuecomment-2336749641

From redestad at openjdk.org  Sun Sep  8 16:57:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Sep 2024 16:57:10 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v10]
In-Reply-To: <Hu7tk4MvGO5PD8cldutRIZ5Op1GfnR_E8cTF5o22BOs=.23bd8d6f-6eb5-46c1-b370-318139dd3aeb@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <Hu7tk4MvGO5PD8cldutRIZ5Op1GfnR_E8cTF5o22BOs=.23bd8d6f-6eb5-46c1-b370-318139dd3aeb@github.com>
Message-ID: <W3-C5KrpkqY4aABsUfH-tfxHyhlA8Y3KO_cc-XKmpUg=.4b8deb44-6c5b-4d95-96b5-9852c6a0099c@github.com>

On Sun, 8 Sep 2024 05:01:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @ExE-Boss 's suggestion

I think this is a reasonable addition and could prove to be an interesting tuning in some applications. But I'd prefer this to be an opt-in feature initially, i.e. setting `java.lang.invoke.StringConcat.cacheThreshold` default value to something like 256. Get the opt-in feature out into a release, advertise its presence, battle-test it and see if there's a sweet spot that we might converge towards as a default with empirical data.

-------------

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20675#pullrequestreview-2288571602

From liach at openjdk.org  Sun Sep  8 17:12:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 8 Sep 2024 17:12:07 GMT
Subject: RFR: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases [v2]
In-Reply-To: <WB5X3XqABp1V9dfk8BI_GOSMFoqdPlKwENRIbd6PLy4=.6272dce1-1f32-42bd-8a27-c3ba309f90ce@github.com>
References: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
 <WB5X3XqABp1V9dfk8BI_GOSMFoqdPlKwENRIbd6PLy4=.6272dce1-1f32-42bd-8a27-c3ba309f90ce@github.com>
Message-ID: <lr7rzC9Jur91jaMPzr5CRT380UhXuCSSEuUlwHo4AnE=.fa7ce27c-f1d8-4280-bbbd-9be9e2758327@github.com>

On Sun, 8 Sep 2024 16:48:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add DMB.withFlags for consistency

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20904#pullrequestreview-2288573681

From swen at openjdk.org  Mon Sep  9 01:53:01 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 9 Sep 2024 01:53:01 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v11]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @cl4es

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/711e96d6..6c69ab34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From swen at openjdk.org  Mon Sep  9 02:15:45 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 9 Sep 2024 02:15:45 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v3]
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <4EtU15TN-gj0IAuG4Sgjn19t3JvsHA0eGIe6GQHjCcM=.8a05aea4-a450-44ab-a386-21b1aea0dcdd@github.com>

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Let the caller ensure that prefix and suffix are not null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20726/files
  - new: https://git.openjdk.org/jdk/pull/20726/files/5025729d..0cacd090

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=01-02

  Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From dholmes at openjdk.org  Mon Sep  9 05:04:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Sep 2024 05:04:08 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
Message-ID: <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>

On Sat, 7 Sep 2024 00:39:16 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
>> 
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
>> 
>> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
>> 
>> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
>> 
>> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
>> 
>> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.
>
> test/lib/jdk/test/lib/util/ForceGC.java line 82:
> 
>> 80:         PhantomReference<Object> ref = new PhantomReference<>(obj, queue);
>> 81:         Reference.reachabilityFence(obj);
>> 82:         obj = null;
> 
> You're right to question the utility of calling reachabilityFence(obj) after obj has been nulled out. But I'm still questioning the utility of calling RF(obj) at all. We don't care when obj is determined to be unreachable; what we care about is that the GC has done some reference processing. Seems to me we can simplify the above lines to
> 
>     PhantomReference<Object> ref = new PhantomReference<>(new Object(), queue);
> 
> and get rid of the local variable obj entirely.

The reason for the explicit reference and RF, as I recall, is to guard against the allocation of the new object being elided entirely, with the `PhantomReference` constructor being passed null (or itself being elided) and no reference processing ever actually happening.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1749562854

From galder at openjdk.org  Mon Sep  9 05:10:07 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 9 Sep 2024 05:10:07 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <CHRIr_xpEwxbARkwjotz31EbbjuyOofbhbDf3t1A3rg=.3830a77d-89b7-439e-bc25-78d46ad43199@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <jgrN6hGqHRGDUm8KHX_vpA-Ce9ayHtlTMsfyZyP_pp8=.1f057307-2ae1-4d62-9ddd-4c85b3cefba5@github.com>
 <CHRIr_xpEwxbARkwjotz31EbbjuyOofbhbDf3t1A3rg=.3830a77d-89b7-439e-bc25-78d46ad43199@github.com>
Message-ID: <R6RIDpx9xJrU8Dsv4rvHntfOWfx_edxUKeGsV70Yng8=.927f7bc1-efc1-448b-9b91-239e67410287@github.com>

On Tue, 3 Sep 2024 07:37:33 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Working on it
>
> @galderz in the benchmark did you collected the mispredicts/branches?

@franz1981 No I hadn't done so until now, but I will be tracking those more closely.

Context:

I have been running some reduction JMH benchmarks and I could see a big drop in non AVX-512 performance compared to the unpatched code. E.g.


    @Benchmark
    public long reductionSingleLongMax() {
        long result = 0;
        for (int i = 0; i < size; i++) {
            final long v = 11 * aLong[i];
            result = Math.max(result, v);
        }
        return result;
    }


This is caused by keeping the Max/Min nodes in the IR, which get translated into `cmpq+cmovlq` instructions (via the macro expansion). The code gets unrolled but a dependency chain on the current max value. In the unpatched code the intrinsic does not kick in and uses a standard ternary operation, which gets translated into a normal control flow. The system is able to handle this better due to branch prediction. @franz1981's comment is precisely about this. I need to enhance the benchmark to control the branchiness of the test (e.g. how often it goes one side or the other of a max/min call) and measure the mispredictions and branches...etc.

FYI: A similar situation can be replicated with reduction benchmarks that use max/min integer, but for the code to fallback into `cmov`, both AVX and SSE have be turned off.

I also need to see what the performance looks on like on a system with AVX-512, and also look at how non-reduction JMH benchmarks behave on systems with/without AVX-512.

Finally, I'm also looking at an experiment to see what would happen in cmovl was implemented with branch+mov instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2337131179

From swen at openjdk.org  Mon Sep  9 05:38:52 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 9 Sep 2024 05:38:52 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v4]
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <eZhRikZWObH6M0lvil4S8s9grefCnCyIeY7LJ_MBJhs=.3f58b60f-2325-407f-9e7d-d82a4cfc887a@github.com>

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove 2 arguments simple concat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20726/files
  - new: https://git.openjdk.org/jdk/pull/20726/files/0cacd090..202934ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=02-03

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From swen at openjdk.org  Mon Sep  9 05:46:40 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 9 Sep 2024 05:46:40 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v5]
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <JK-cRfCnXim17rD_sqtWqkaqNGtjRREe2tI6W9evnvc=.d83e8786-7ba2-4b48-aed5-fec7060b57ab@github.com>

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  reduce changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20726/files
  - new: https://git.openjdk.org/jdk/pull/20726/files/202934ad..f63e6a7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From redestad at openjdk.org  Mon Sep  9 05:56:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 05:56:10 GMT
Subject: RFR: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases [v2]
In-Reply-To: <WB5X3XqABp1V9dfk8BI_GOSMFoqdPlKwENRIbd6PLy4=.6272dce1-1f32-42bd-8a27-c3ba309f90ce@github.com>
References: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
 <WB5X3XqABp1V9dfk8BI_GOSMFoqdPlKwENRIbd6PLy4=.6272dce1-1f32-42bd-8a27-c3ba309f90ce@github.com>
Message-ID: <PyZyvMtsVXIvkDN6JPo2c3JUxbqV402ztzZMsLFoQ7Y=.4575650a-6e2c-481c-b535-b609c2c82dc1@github.com>

On Sun, 8 Sep 2024 16:48:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add DMB.withFlags for consistency

Thanks for reviewing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20904#issuecomment-2337184421

From redestad at openjdk.org  Mon Sep  9 05:56:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 05:56:11 GMT
Subject: Integrated: 8339710: Avoid initializing AccessFlag related classes in
 write-only cases
In-Reply-To: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
References: <EPLQ3fXu9UdwmN87FOk6USx1GT3YVggrIhZuu-m99zI=.91cb7bd7-c050-4582-9a4b-9abd73a15a9f@github.com>
Message-ID: <eAOLYRZirjr8MTVw6mohQxpvZwrkJktyD1u8gn8Zz1s=.d2b36e5c-8d00-448b-bd68-e0d5fbbd31de@github.com>

On Sun, 8 Sep 2024 13:17:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR reduces number of classes loaded on a minimal lambda bootstrapping test by 4 by avoiding the need to pull in some AccessFlag classes.

This pull request has now been integrated.

Changeset: b45fe174
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b45fe174500f4bc38a0bb703c81614355404ae4f
Stats:     39 lines in 3 files changed: 36 ins; 0 del; 3 mod

8339710: Avoid initializing AccessFlag related classes in write-only cases

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20904

From alanb at openjdk.org  Mon Sep  9 06:28:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Sep 2024 06:28:45 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v4]
In-Reply-To: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
Message-ID: <tI_Z8KU9mFxsgFBy2xtDEdRH5ukDoz8ec-iYKfQpsBw=.9797399c-50e1-4ca7-a099-9fac0ef4500c@github.com>

> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html) and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
> 
> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
> 
> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
> 
> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).

Alan Bateman 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:

 - Remove unused code, expand testing
 - Merge
 - Sync up from loom repo
 - Merge
 - Sync up from loom repo
 - Merge
 - Sync up from loom repo
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20816/files
  - new: https://git.openjdk.org/jdk/pull/20816/files/189d5467..e5a4c825

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20816&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20816&range=02-03

  Stats: 2284 lines in 67 files changed: 1409 ins; 352 del; 523 mod
  Patch: https://git.openjdk.org/jdk/pull/20816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20816/head:pull/20816

PR: https://git.openjdk.org/jdk/pull/20816

From coffeys at openjdk.org  Mon Sep  9 06:31:04 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 9 Sep 2024 06:31:04 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3]
In-Reply-To: <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
 <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
Message-ID: <SLChNqdCB9zfAhQ6wJv-6mbefYEqBgq-eCYg8g9kKb4=.b197ee36-0c05-4e0a-bb92-e5d8d816e534@github.com>

On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strictly conforming to the spec

Marked as reviewed by coffeys (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2288924261

From mbaesken at openjdk.org  Mon Sep  9 07:06:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Sep 2024 07:06:22 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v4]
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <-jOsJFxPMFg7FACIElJmHxXUP3V2ChQvuukRhMfCBAo=.b984ef94-a3a4-49bf-a6cd-ac704a55ed52@github.com>

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20839/files
  - new: https://git.openjdk.org/jdk/pull/20839/files/afc423ad..a8c85318

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20839&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20839&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20839/head:pull/20839

PR: https://git.openjdk.org/jdk/pull/20839

From mbaesken at openjdk.org  Mon Sep  9 07:06:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Sep 2024 07:06:23 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v3]
In-Reply-To: <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <MpUvHLTrMVlXAnyYMi0a5U4caxnuaFDaEVah1Vbar_M=.6f9a8241-248a-403e-a3a8-76ace76afc33@github.com>
Message-ID: <DE-GBNSTAi0MY6YU20HjHSa_qJ6eEpfnmlV9eakNuDk=.ae271c0e-eae0-4886-989f-9e5ebea84703@github.com>

On Fri, 6 Sep 2024 07:05:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for ENOMEM

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20839#issuecomment-2337290676

From alanb at openjdk.org  Mon Sep  9 07:09:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Sep 2024 07:09:06 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v4]
In-Reply-To: <-jOsJFxPMFg7FACIElJmHxXUP3V2ChQvuukRhMfCBAo=.b984ef94-a3a4-49bf-a6cd-ac704a55ed52@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <-jOsJFxPMFg7FACIElJmHxXUP3V2ChQvuukRhMfCBAo=.b984ef94-a3a4-49bf-a6cd-ac704a55ed52@github.com>
Message-ID: <HFk9zXB_lohVwsqTp4DDOnTp13SvWsyWFr8Z4NuAeQ0=.3e17005b-3937-4e18-a0dc-fb975b5125d5@github.com>

On Mon, 9 Sep 2024 07:06:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2288987041

From mbaesken at openjdk.org  Mon Sep  9 07:38:11 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Sep 2024 07:38:11 GMT
Subject: Integrated: 8339487: ProcessHandleImpl os_getChildren sysctl call -
 retry in case of ENOMEM and enhance exception message
In-Reply-To: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
Message-ID: <Oh-Ub9BLaF-rZZ62OWPyZkFv05Si9GsQr6lWWgF76fI=.5700ad99-3412-4f51-9ddb-e037a1442a82@github.com>

On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
> 
> java.lang.RuntimeException: Cannot allocate memory
>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 
> 
> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.

This pull request has now been integrated.

Changeset: 4ff72dc5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ff72dc57e65e99b129f0ba28196994edf402018
Stats:     29 lines in 2 files changed: 11 ins; 1 del; 17 mod

8339487: ProcessHandleImpl os_getChildren sysctl call - retry in case of ENOMEM and enhance exception message

Reviewed-by: alanb, lucy, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/20839

From lucy at openjdk.org  Mon Sep  9 08:07:08 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 9 Sep 2024 08:07:08 GMT
Subject: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry
 in case of ENOMEM and enhance exception message [v4]
In-Reply-To: <-jOsJFxPMFg7FACIElJmHxXUP3V2ChQvuukRhMfCBAo=.b984ef94-a3a4-49bf-a6cd-ac704a55ed52@github.com>
References: <xefC5AqwHPTAX2warJ-OTBCyJWAJACzj0M3udEgLCy4=.02170908-37ad-4422-8ec6-86bff8aa58ad@github.com>
 <-jOsJFxPMFg7FACIElJmHxXUP3V2ChQvuukRhMfCBAo=.b984ef94-a3a4-49bf-a6cd-ac704a55ed52@github.com>
Message-ID: <_n7I9PdqLq_Qf3WJeT2iaPx2ILMoTmU-m1zfI8thWuo=.06f314ef-3443-4fd9-8ea8-ae871aef82b8@github.com>

On Mon, 9 Sep 2024 07:06:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, a few times this error occurs :
>> 
>> java.lang.RuntimeException: Cannot allocate memory
>>        at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456)
>>        at java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434)
>>        at PermissionTest.childrenWithPermission(PermissionTest.java:84)
>>        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>> 
>> 
>> Probably sysctl fails here, but it is not fully clear; it would help to change the exception so that the standard text is shown too in the exception message.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Still looking good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2289129121

From jbhateja at openjdk.org  Mon Sep  9 08:18:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Sep 2024 08:18:54 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v9]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <9NBW5WfztEJCcHs68o3b8O1IhgmdS3LX7UQmZXxbZ8M=.0271ce97-7dbe-4f84-965d-d511b0392c5b@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with two additional commits since the last revision:

 - Fix jtreg regression.
 - Addressing Paul's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/195390fe..4a93042b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=07-08

  Stats: 215 lines in 39 files changed: 0 ins; 1 del; 214 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From sundar at openjdk.org  Mon Sep  9 09:11:04 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 9 Sep 2024 09:11:04 GMT
Subject: RFR: 8337422: spelling error in jlink documentation
In-Reply-To: <quNiZh02xsxihMylz1Q0-SGDiaDXpUpEbhVU_nIlF_Q=.f8a99251-f538-4a32-97e2-7624942a28eb@github.com>
References: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
 <quNiZh02xsxihMylz1Q0-SGDiaDXpUpEbhVU_nIlF_Q=.f8a99251-f538-4a32-97e2-7624942a28eb@github.com>
Message-ID: <gRjD5HBGVNnCpVjy-hVWi0wTrmlilSwPUEq7xs33uik=.f0e2744a-2430-480d-8b43-135b4f9bab07@github.com>

On Fri, 6 Sep 2024 08:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> fixed spelling to be consistent with the rest of the man page.
>
> I checked the OED and it does seem to be uncountable, which makes me wonder about other places, e.g. JLS 7.7.1.

@AlanBateman @pavelrappo  I did double check. "dependence" is an uncountable noun.

https://dictionary.cambridge.org/dictionary/english/dependence

dependence
noun [[ U ]](https://dictionary.cambridge.org/help/codes.html)

https://www.collinsdictionary.com/dictionary/english/dependence

How do I proceed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20882#issuecomment-2337558963

From prappo at openjdk.org  Mon Sep  9 09:19:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 09:19:38 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v3]
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years
  
  Note: any commit hashes below might be outdated due to subsequent
  history rewriting (e.g. git rebase).
  
   + update src/java.base/share/classes/java/lang/ClassLoader.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/Record.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/StackWalker.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/reflect/AccessFlag.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/reflect/InvocationHandler.java due to 51ffa5ee21b
   + update src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java due to 51ffa5ee21b
   + update src/java.compiler/share/classes/javax/lang/model/type/NullType.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java due to 2c3d47aad82
   + update src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java due to 51ffa5ee21b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20879/files
  - new: https://git.openjdk.org/jdk/pull/20879/files/2c3d47aa..c9518c85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=01-02

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20879/head:pull/20879

PR: https://git.openjdk.org/jdk/pull/20879

From prappo at openjdk.org  Mon Sep  9 09:19:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 09:19:38 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <w1Tp8gpthta4aiyckqPCgYBYT-d48cE7zYiIhtf6M38=.80190c3b-e495-4eef-a313-58da5ac99fe8@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

Ugh... The most recent change to copyright years caused the bot to remove the "ready" label. Please re-review; thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2337578863

From kevinw at openjdk.org  Mon Sep  9 09:49:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Sep 2024 09:49:08 GMT
Subject: RFR: 8338890: Add monitoring/management interface for the virtual
 thread scheduler [v4]
In-Reply-To: <tI_Z8KU9mFxsgFBy2xtDEdRH5ukDoz8ec-iYKfQpsBw=.9797399c-50e1-4ca7-a099-9fac0ef4500c@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
 <tI_Z8KU9mFxsgFBy2xtDEdRH5ukDoz8ec-iYKfQpsBw=.9797399c-50e1-4ca7-a099-9fac0ef4500c@github.com>
Message-ID: <cdhdMXZwq37mu-eYmgK1cX4mCKCVm7qTXxrpNMDrmP8=.c7cffc5d-fb2a-4cc7-806c-ee877fc4cab0@github.com>

On Mon, 9 Sep 2024 06:28:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html) and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
>> 
>> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
>> 
>> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
>> 
>> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).
>
> Alan Bateman 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:
> 
>  - Remove unused code, expand testing
>  - Merge
>  - Sync up from loom repo
>  - Merge
>  - Sync up from loom repo
>  - Merge
>  - Sync up from loom repo
>  - Initial commit

Updates look good to me.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20816#pullrequestreview-2289417860

From syan at openjdk.org  Mon Sep  9 09:56:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 09:56:13 GMT
Subject: RFR: 8339714: Delete tedious bool type define
Message-ID: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>

Hi all,
  This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
  Make code more concision, the risk is quite low.

Additional testing:

- [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
- [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
- [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

-------------

Commit messages:
 - 8339714: Delete tedious bool type define

Changes: https://git.openjdk.org/jdk/pull/20909/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20909&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339714
  Stats: 14 lines in 2 files changed: 1 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20909/head:pull/20909

PR: https://git.openjdk.org/jdk/pull/20909

From duke at openjdk.org  Mon Sep  9 10:17:20 2024
From: duke at openjdk.org (duke)
Date: Mon, 9 Sep 2024 10:17:20 GMT
Subject: Withdrawn: 8307818: Convert Indify tool to Classfile API
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <jciYcu7y5XGicl92INBUS1Jlh9OcsRjDIqvBAGg4LoU=.78770123-0a25-44ac-92a0-f7bfb6bae896@github.com>

On Thu, 18 Apr 2024 13:53:34 GMT, Oussama Louati <duke at openjdk.org> wrote:

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> ### Purpose of Indify
> 
> -  **Transformation Tool**: `Indify` transforms existing class files to leverage `invokedynamic` and other JSR 292 features. This transformation allows for dynamic method calls.
> 
> ### Key Functions
> 
> - **Method Handle and Method Type Constants**:
>     - **MH_x and MT_x Methods**: These methods are used to generate `MethodHandle` and `MethodType` constants. The tool transforms calls to these methods into `CONSTANT_MethodHandle` and `CONSTANT_MethodType` "ldc" (load constant) instructions.
> -  **Invokedynamic Call Sites**:
>     - **INDY_x Methods**: These methods generate `invokedynamic` call sites. Each `INDY_x` method starts with a call to an `MH_x` method, which acts as the bootstrap method. This is followed by an `invokeExact` call.
>     - **Transformation**: The tool transforms pairs of calls (to `INDY_x` followed by `invokeExact`) into `invokedynamic` instructions. This mimics the JVM's handling of `invokedynamic` instructions, creating dynamic call sites that are linked at runtime.
> 
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18841

From redestad at openjdk.org  Mon Sep  9 11:21:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 11:21:30 GMT
Subject: RFR: 8339742: Refactor ClassFileImpl to allow loading Option classes
 lazily
Message-ID: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>

Refactor ClassFileImpl so that Option classes are not eagerly loaded.

- Reduces number of classes loaded on various startup tests (typically 15 classes less)
- Reduces size of the default CDS archive by ~30Kb

-------------

Commit messages:
 - Cleanup, fix failing test
 - Refactor ClassFileImpl option handling to load fewer classes up front

Changes: https://git.openjdk.org/jdk/pull/20911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339742
  Stats: 146 lines in 7 files changed: 82 ins; 11 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/20911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20911/head:pull/20911

PR: https://git.openjdk.org/jdk/pull/20911

From asotona at openjdk.org  Mon Sep  9 11:37:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 9 Sep 2024 11:37:05 GMT
Subject: RFR: 8339742: Refactor ClassFileImpl to allow loading Option
 classes lazily
In-Reply-To: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>
References: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>
Message-ID: <HFZNrD9CXmF2VqxAXhYF5f9M4YbDUdniOPZMwKs-OAw=.3f8da9cf-ab5b-4209-b2c8-c617b0367caf@github.com>

On Mon, 9 Sep 2024 11:16:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Refactor ClassFileImpl so that Option classes are not eagerly loaded.
> 
> - Reduces number of classes loaded on various startup tests (typically 15 classes less)
> - Reduces size of the default CDS archive by ~30Kb

It looks good to me and it does not seem to change the options defaults.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20911#pullrequestreview-2289642825

From aefimov at openjdk.org  Mon Sep  9 11:42:25 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 11:42:25 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:

 - guard against possible integer value overflows
 - make startTime a local variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/6c437cc3..30f883b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=00-01

  Stats: 9 lines in 2 files changed: 1 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From aefimov at openjdk.org  Mon Sep  9 11:42:25 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 11:42:25 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <XaEiYNzheaIhDuaVO1GK5zC8YfEyB_84RVBuv4xo3KU=.1df7ab6f-7017-40be-b3af-7c6668458c55@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <XaEiYNzheaIhDuaVO1GK5zC8YfEyB_84RVBuv4xo3KU=.1df7ab6f-7017-40be-b3af-7c6668458c55@github.com>
Message-ID: <mYojjhFAhl8HBBVrVx5kJdqd7thr7CZ_JViL0htc2fI=.0fc17ae7-aa19-4772-8d51-aae290882e7b@github.com>

On Sat, 7 Sep 2024 13:12:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - guard against possible integer value overflows
>>  - make startTime a local variable
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 478:
> 
>> 476:                     long elapsedMillis = Math.max(1,
>> 477:                             TimeUnit.NANOSECONDS.toMillis(end - start));
>> 478:                     timeoutLeft = timeoutLeft - (int) elapsedMillis;
> 
> Hello Aleksei, should this `int` cast take into account potential integer value overflow? In theory (and probably even in practice depending on what the initial timeout value was configured to), the `elapsedMillis`, I think can be a value greater than `Integer.MAX_VALUE`, in which case this cast to `int` can cause unexpected computation of `timeoutLeft`.

Thanks for highlighting the overflow problem, Jaikiran. I agree that it could happen in practice when timeout and retries configuration properties specify timeout value close to `Integer.MAX_VALUE`. Addressed it in 30f883b8cb31120907002191dbfd88d787c75ec8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750097522

From aefimov at openjdk.org  Mon Sep  9 11:42:25 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 11:42:25 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <6qETkq7VNDP0WAtt_6Sln79FED60jobIsyMHQRY5G2Q=.291dd7a9-ec7c-4623-8dc7-66a86d5d8e45@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6qETkq7VNDP0WAtt_6Sln79FED60jobIsyMHQRY5G2Q=.291dd7a9-ec7c-4623-8dc7-66a86d5d8e45@github.com>
Message-ID: <ofMTHzxiiXhfcUWxGSl4xMo9FgjcHw7GMNXHAmv_Qhs=.0f127818-f1c3-4d0d-a552-3bd0b913d5fa@github.com>

On Fri, 6 Sep 2024 16:58:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - guard against possible integer value overflows
>>  - make startTime a local variable
>
> test/jdk/com/sun/jndi/dns/ConfigTests/TimeoutWithEmptyDatagrams.java line 62:
> 
>> 60:     private static final int DNS_CLIENT_MIN_TIMEOUT = 50;
>> 61: 
>> 62:     private long startTime;
> 
> startTime does not need to be an instance variable: consider removing it and make it a local variable in the runTest() method.

Thanks Daniel, made it locat variable in the `runTest` method: 11d0f3d038360c04710d78bd8cd036743f69fe41

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750096686

From liach at openjdk.org  Mon Sep  9 12:09:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 12:09:06 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v3]
In-Reply-To: <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>
Message-ID: <19ozWfaawKNwfzfhGYjnNfSB-S9SYGmPSvFYT5CRob0=.07c930ac-f9e7-4d38-81d3-3528608c5eb0@github.com>

On Mon, 9 Sep 2024 09:19:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years
>   
>   Note: any commit hashes below might be outdated due to subsequent
>   history rewriting (e.g. git rebase).
>   
>    + update src/java.base/share/classes/java/lang/ClassLoader.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/Record.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/StackWalker.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/reflect/AccessFlag.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/reflect/InvocationHandler.java due to 51ffa5ee21b
>    + update src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java due to 51ffa5ee21b
>    + update src/java.compiler/share/classes/javax/lang/model/type/NullType.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java due to 2c3d47aad82
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java due to 51ffa5ee21b

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2289709280

From prappo at openjdk.org  Mon Sep  9 12:09:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 12:09:07 GMT
Subject: Integrated: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <562NEVvPnRZm-wYVGCbsiMk1JR0xzN1BUOSQ1tlv2YU=.0c338c07-d988-4f94-b1d1-fcfd0736d13e@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

This pull request has now been integrated.

Changeset: 88cccc14
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88cccc14db168876a60b5ea2ae9d0fda7969af9a
Stats:     54 lines in 22 files changed: 1 ins; 1 del; 52 mod

8339631: Fix block @jls and @jvms tags

Reviewed-by: liach, darcy, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/20879

From jwaters at openjdk.org  Mon Sep  9 12:10:09 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 9 Sep 2024 12:10:09 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

Hmm. While I want to put my support behind this change, I recall that an earlier proposal that I made to implement jbooleans with stdbool.h being rejected due to backwards incompatibility, and some places really do expect an int and not a bool type. What are the likelihoods that a place in the code here is actually expecting an int due to ABI issues?

src/java.base/unix/native/libjsig/jsig.c line 46:

> 44: #include <string.h>
> 45: 
> 46: #if (__STDC_VERSION__ >= 199901L)

Since this does include stdbool.h already, this change looks ok

src/utils/hsdis/binutils/hsdis-binutils.c line 67:

> 65: #include "hsdis.h"
> 66: 
> 67: #ifndef bool

I'm a little worried about this change. hsdis may really need an int here. If that turns out to not be the case then I'll retract my concerns

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2337942768
PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750135891
PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750137910

From jvernee at openjdk.org  Mon Sep  9 12:34:07 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 9 Sep 2024 12:34:07 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v5]
In-Reply-To: <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
Message-ID: <SwEkQEXmK_YgzILUq-2NlhZbDrplP2USigvaSpo2aRE=.5c6ee96d-d373-4af1-991f-42b14c1d17c8@github.com>

On Fri, 6 Sep 2024 17:51:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove PC save/restore on s390

src/hotspot/share/prims/upcallLinker.cpp line 160:

> 158: 
> 159:   assert(entry->method_holder()->is_initialized(), "no clinit barrier");
> 160:   CompilationPolicy::compile_if_required(mh_entry, CHECK_0);

Note that this call to `compile_if_required` doesn't make sense here, since the target method can change (through a race). But also: we already call `compile_if_required` for the target of a method handle in `CallInfo::set_common`, which we reach when resolving the target `vmentry` (a `MemberName`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1750172834

From syan at openjdk.org  Mon Sep  9 12:53:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:53:06 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
 <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>
Message-ID: <lmQLmA7lCXqDXHHn__RvvmXQuih0r0786WmQti2F_78=.fc010b70-34c9-495a-95a4-9cd14eb661d2@github.com>

On Mon, 9 Sep 2024 12:06:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Hi all,
>>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>>   Make code more concision, the risk is quite low.
>> 
>> Additional testing:
>> 
>> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
>> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
>> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64
>
> src/java.base/unix/native/libjsig/jsig.c line 46:
> 
>> 44: #include <string.h>
>> 45: 
>> 46: #if (__STDC_VERSION__ >= 199901L)
> 
> Since this does include stdbool.h already, this change looks ok

Okey.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750201356

From syan at openjdk.org  Mon Sep  9 12:59:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:59:06 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
 <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>
Message-ID: <bT7mXWwBa5Cv9yqoA-Ns7JPGAP-voM8fPXTgiyR_2l0=.3358d400-ed50-4bbd-ac6d-c366d9bf57aa@github.com>

On Mon, 9 Sep 2024 12:07:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Hi all,
>>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>>   Make code more concision, the risk is quite low.
>> 
>> Additional testing:
>> 
>> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
>> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
>> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64
>
> src/utils/hsdis/binutils/hsdis-binutils.c line 67:
> 
>> 65: #include "hsdis.h"
>> 66: 
>> 67: #ifndef bool
> 
> I'm a little worried about this change. hsdis may really need an int here. If that turns out to not be the case then I'll retract my concerns

I have verified this change locally, include build hsdis.so and check the functional with command java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version. The verified show this change for hsdis.so work normally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750211438

From mcimadamore at openjdk.org  Mon Sep  9 13:02:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 13:02:15 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <HZIkgWxq3qbji5g5CcwUcrOrGyMycwv2R2JdD5Usvxc=.916fb76b-626e-4bbf-bccd-6b86a752ac15@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java line 9:

> 7:  * This allows to avoid pesky initialization issues in the middle of memory mapped scoped methods.
> 8:  */
> 9: public interface MappedMemoryUtilsProxy {

We should probably try to consolidate this and `UmapperProxy` - I think it can be done, but it requires deeper surgery than I was willing to do in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750215021

From mcimadamore at openjdk.org  Mon Sep  9 13:02:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 13:02:15 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
Message-ID: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>

The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.

To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.

Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/20914/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339686
  Stats: 104 lines in 7 files changed: 48 ins; 30 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/20914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914

PR: https://git.openjdk.org/jdk/pull/20914

From jwaters at openjdk.org  Mon Sep  9 13:06:06 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 9 Sep 2024 13:06:06 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <55oOaRmeL9m8LqNBmJgL3HKHI5QJ0WHm4ahcOneNt8k=.bfa57937-f3fe-41d3-b514-3d5444bde093@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20909#pullrequestreview-2289852123

From jwaters at openjdk.org  Mon Sep  9 13:06:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 9 Sep 2024 13:06:07 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <bT7mXWwBa5Cv9yqoA-Ns7JPGAP-voM8fPXTgiyR_2l0=.3358d400-ed50-4bbd-ac6d-c366d9bf57aa@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
 <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>
 <bT7mXWwBa5Cv9yqoA-Ns7JPGAP-voM8fPXTgiyR_2l0=.3358d400-ed50-4bbd-ac6d-c366d9bf57aa@github.com>
Message-ID: <UBPen5z1L96O_lkRN9b7Oa6pQk2FPZSZH6TW6z_CkPw=.3f618e91-8248-4f3b-b2d2-bec66b69a7c7@github.com>

On Mon, 9 Sep 2024 12:56:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> src/utils/hsdis/binutils/hsdis-binutils.c line 67:
>> 
>>> 65: #include "hsdis.h"
>>> 66: 
>>> 67: #ifndef bool
>> 
>> I'm a little worried about this change. hsdis may really need an int here. If that turns out to not be the case then I'll retract my concerns
>
> I have verified this change locally, include build hsdis.so and check the functional with command java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version. The verified show this change for hsdis.so work normally.

Ok, sounds good

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750222067

From syan at openjdk.org  Mon Sep  9 13:20:07 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 13:20:07 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <UBPen5z1L96O_lkRN9b7Oa6pQk2FPZSZH6TW6z_CkPw=.3f618e91-8248-4f3b-b2d2-bec66b69a7c7@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
 <L9YPtx1u49qsWfnqlGnwKGxz4ogsOxV6Re8MepQwq_c=.15b0a852-c580-4fb5-808f-37efd1b6986a@github.com>
 <bT7mXWwBa5Cv9yqoA-Ns7JPGAP-voM8fPXTgiyR_2l0=.3358d400-ed50-4bbd-ac6d-c366d9bf57aa@github.com>
 <UBPen5z1L96O_lkRN9b7Oa6pQk2FPZSZH6TW6z_CkPw=.3f618e91-8248-4f3b-b2d2-bec66b69a7c7@github.com>
Message-ID: <EY-r6CpfiLD3p6sS6zX1w9bYSVuPv44VRRIBHs2bRk8=.016608ae-df49-4e47-b87f-a60b2a0915b2@github.com>

On Mon, 9 Sep 2024 13:03:49 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I have verified this change locally, include build hsdis.so and check the functional with command java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version. The verified show this change for hsdis.so work normally.
>
> Ok, sounds good

Thanks for the review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750243576

From mcimadamore at openjdk.org  Mon Sep  9 13:28:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 13:28:12 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <L8bW6WHUtMpYyz-Ni_E3ixk8uBCwXdTOlndX8cG6j0E=.cd377fbf-f420-4921-841a-1a0014d5a723@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 255:

> 253:                 session.checkValidStateRaw();
> 254:             }
> 255:             return mappedUtils.isLoaded(address, isSync, size);

this method (and other related methods) now only performs a straight call into `MappedMemoryUtilsProxy`. Static initializers and JNI resolution has already run, so we should no longer use too much stack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750259314

From jvernee at openjdk.org  Mon Sep  9 13:35:08 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 9 Sep 2024 13:35:08 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <hX8tjxSP3pY1q3MRisN4iqWtSQOcuV6oaK4t5jXBRuI=.9aa25ba0-42f3-48db-b8c9-16e5da353d97@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20914#pullrequestreview-2289932524

From djelinski at openjdk.org  Mon Sep  9 14:01:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 9 Sep 2024 14:01:05 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
Message-ID: <Oyvs4mAve9Ig-HV-BB-2CoToeUJ2t1Ys_oMg4LNn0uE=.0af35357-4da7-4f6e-a980-83ce9b29b2b1@github.com>

On Mon, 9 Sep 2024 11:42:25 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - guard against possible integer value overflows
>  - make startTime a local variable

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 477:

> 475:                     long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end - start);
> 476:                     // Setting the Math.clamp min to 1 ensures that the timeout is decreased
> 477:                     timeoutLeft = timeoutLeft - Math.clamp(elapsedMillis, 1, Integer.MAX_VALUE);

I think I'd prefer to calculate the remaining timeout based on the total elapsed time in this loop, as opposed to the time spent in blockingReceive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750323475

From redestad at openjdk.org  Mon Sep  9 14:17:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 14:17:04 GMT
Subject: RFR: 8339742: Refactor ClassFileImpl to allow loading Option
 classes lazily
In-Reply-To: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>
References: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>
Message-ID: <5gznQfDtIoYAb4jZygkKlF6P2CG8QH0uof8JVqjKaWQ=.5782b283-740f-4a62-ae98-3b2beeeb072f@github.com>

On Mon, 9 Sep 2024 11:16:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Refactor ClassFileImpl so that Option classes are not eagerly loaded.
> 
> - Reduces number of classes loaded on various startup tests (typically 15 classes less)
> - Reduces size of the default CDS archive by ~30Kb

Thanks for the reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20911#issuecomment-2338245453

From redestad at openjdk.org  Mon Sep  9 14:21:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 14:21:11 GMT
Subject: Integrated: 8339742: Refactor ClassFileImpl to allow loading Option
 classes lazily
In-Reply-To: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>
References: <vRePWP9ZgwApwJbbiWp6otfdfH_OfcbpYvAVxaATCaY=.f3319610-54f2-4789-a767-9da3dec05413@github.com>
Message-ID: <SA5qgFUHLgl6ZCvjlgpcwP5sedhElcE8YUJ9d2WuCDg=.8d24ebac-e5e8-48f3-8821-21bca43e63a3@github.com>

On Mon, 9 Sep 2024 11:16:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Refactor ClassFileImpl so that Option classes are not eagerly loaded.
> 
> - Reduces number of classes loaded on various startup tests (typically 15 classes less)
> - Reduces size of the default CDS archive by ~30Kb

This pull request has now been integrated.

Changeset: d53e405a
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d53e405a26e53086d46ce78a9792f0ca72cca529
Stats:     146 lines in 7 files changed: 82 ins; 11 del; 53 mod

8339742: Refactor ClassFileImpl to allow loading Option classes lazily

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20911

From redestad at openjdk.org  Mon Sep  9 14:23:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 14:23:06 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
 <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
Message-ID: <veDEqnawNZ1-YuPFeGgg3cls52FAwY8Sa7tuPswAsP4=.309fcb7f-38f3-4d18-822f-720ffed9b82d@github.com>

On Fri, 6 Sep 2024 19:55:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not try to classdata non-live lambda forms in pre-generation

Looks good. And getting `Utf8Entry`s from the `FieldRefEntry` should help reduce constant pool lookups a bit.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20896#pullrequestreview-2290080133

From mdoerr at openjdk.org  Mon Sep  9 14:26:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 9 Sep 2024 14:26:04 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <V3qRV7mjtDBEK6YN42PwhxKdKTR7hS9PtH4pcJBId7s=.fb81e077-a87d-4132-918e-583b2a2d0694@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

This resolves one of the issues on AIX, but [JDK-8339780](https://bugs.openjdk.org/browse/JDK-8339780) is still a problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20914#issuecomment-2338269170

From redestad at openjdk.org  Mon Sep  9 14:29:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 14:29:08 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v11]
In-Reply-To: <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
Message-ID: <l_BEPR21YEcWuayEq6sKybYmkeo-Sf9152kq8776Jj8=.d00172cf-d2e6-45d2-b53b-a9d932b14173@github.com>

On Mon, 9 Sep 2024 01:53:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @cl4es

I think this looks ok.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20675#pullrequestreview-2290095706

From dfuchs at openjdk.org  Mon Sep  9 14:44:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Sep 2024 14:44:10 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
 <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
Message-ID: <TNpBRQXgl8LsGeWx4LSoEr-33XIdq_uSiRwyaOhN2mM=.f80a547c-db10-44d8-80a2-4d882e4391ce@github.com>

On Mon, 9 Sep 2024 05:01:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 82:
>> 
>>> 80:         PhantomReference<Object> ref = new PhantomReference<>(obj, queue);
>>> 81:         Reference.reachabilityFence(obj);
>>> 82:         obj = null;
>> 
>> You're right to question the utility of calling reachabilityFence(obj) after obj has been nulled out. But I'm still questioning the utility of calling RF(obj) at all. We don't care when obj is determined to be unreachable; what we care about is that the GC has done some reference processing. Seems to me we can simplify the above lines to
>> 
>>     PhantomReference<Object> ref = new PhantomReference<>(new Object(), queue);
>> 
>> and get rid of the local variable obj entirely.
>
> The reason for the explicit reference and RF, as I recall, is to guard against the allocation of the new object being elided entirely, with the `PhantomReference` constructor being passed null (or itself being elided) and no reference processing ever actually happening.

What David says ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1750394382

From dfuchs at openjdk.org  Mon Sep  9 14:44:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Sep 2024 14:44:11 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
Message-ID: <t9D3sem9FpIEv_EBlBPQLeg8k9xq80f5gyq2Vh2acMY=.bfd581fb-652d-4e8c-94ea-693922a30a88@github.com>

On Sat, 7 Sep 2024 00:40:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
>> 
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
>> 
>> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
>> 
>> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
>> 
>> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
>> 
>> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.
>
> test/lib/jdk/test/lib/util/ForceGC.java line 102:
> 
>> 100:             }
>> 101:         }
>> 102:         Reference.reachabilityFence(ref);
> 
> I think everything from the creation of ref to the line above needs to enclosed in a try-statement, with the finally-clause including RF(ref).

Arguably the same might also apply to the other call to reachability fence: that is - we might need two try-finally to keep things by-the-book?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1750398105

From aefimov at openjdk.org  Mon Sep  9 14:45:11 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 14:45:11 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <Oyvs4mAve9Ig-HV-BB-2CoToeUJ2t1Ys_oMg4LNn0uE=.0af35357-4da7-4f6e-a980-83ce9b29b2b1@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
 <Oyvs4mAve9Ig-HV-BB-2CoToeUJ2t1Ys_oMg4LNn0uE=.0af35357-4da7-4f6e-a980-83ce9b29b2b1@github.com>
Message-ID: <yw8BCiwm648UHd2LqQNqxaibTkKLaLt_VW_wX7vrwik=.900bd11b-436d-4acc-ad5e-5ec302a96f3a@github.com>

On Mon, 9 Sep 2024 13:58:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - guard against possible integer value overflows
>>  - make startTime a local variable
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 477:
> 
>> 475:                     long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end - start);
>> 476:                     // Setting the Math.clamp min to 1 ensures that the timeout is decreased
>> 477:                     timeoutLeft = timeoutLeft - Math.clamp(elapsedMillis, 1, Integer.MAX_VALUE);
> 
> I think I'd prefer to calculate the remaining timeout based on the total elapsed time in this loop, as opposed to the time spent in blockingReceive.

Sounds like a right thing to do:  measuring time in the loop should give us better estimation on time DNS client spends waiting on the response after submiting a query (that's how environment property value is defined in [javadoc here](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html)).
I've tried to move `start` and `end` like:

                 do {
+                    long start = System.nanoTime();
<....>
-                    long start = System.nanoTime();
                     gotData = blockingReceive(udpChannel, ipkt, timeoutLeft);
-                    long end = System.nanoTime();
<...>
+                    long end = System.nanoTime();
                     long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end - start);

As a result the tests showed that the timeout happened with a bit better precision (10th of milliseconds).
I will run more tests and incorporate the suggestions. Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750402311

From dfuchs at openjdk.org  Mon Sep  9 15:07:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Sep 2024 15:07:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <yw8BCiwm648UHd2LqQNqxaibTkKLaLt_VW_wX7vrwik=.900bd11b-436d-4acc-ad5e-5ec302a96f3a@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
 <Oyvs4mAve9Ig-HV-BB-2CoToeUJ2t1Ys_oMg4LNn0uE=.0af35357-4da7-4f6e-a980-83ce9b29b2b1@github.com>
 <yw8BCiwm648UHd2LqQNqxaibTkKLaLt_VW_wX7vrwik=.900bd11b-436d-4acc-ad5e-5ec302a96f3a@github.com>
Message-ID: <8arNF1zT2CeGesIVagTy5WcJ5303piCVad9Natbsczg=.d4ce9430-0171-4428-aaad-99974b26a7ed@github.com>

On Mon, 9 Sep 2024 14:42:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 477:
>> 
>>> 475:                     long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end - start);
>>> 476:                     // Setting the Math.clamp min to 1 ensures that the timeout is decreased
>>> 477:                     timeoutLeft = timeoutLeft - Math.clamp(elapsedMillis, 1, Integer.MAX_VALUE);
>> 
>> I think I'd prefer to calculate the remaining timeout based on the total elapsed time in this loop, as opposed to the time spent in blockingReceive.
>
> Sounds like a right thing to do:  measuring time in the loop should give us better estimation on time DNS client spends waiting on the response after submiting a query (that's how environment property value is defined in [javadoc here](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html)).
> I've tried to move `start` and `end` like:
> 
>                  do {
> +                    long start = System.nanoTime();
> <....>
> -                    long start = System.nanoTime();
>                      gotData = blockingReceive(udpChannel, ipkt, timeoutLeft);
> -                    long end = System.nanoTime();
> <...>
> +                    long end = System.nanoTime();
>                      long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end - start);
> 
> As a result the tests showed that the timeout happened with a bit better precision (10th of milliseconds).
> I will run more tests and incorporate the suggestions. Thank you.

I have been wondering why the timeout was measured in this way. My explanation was that the original author of the API (duke? ;-) ) wanted to measure "actual timeout" (time actually spent waiting for a packet) as opposed to perceived timeout (time the caller spent waiting). Rationale might have been to exclude potential time spent waiting for a lock before entering receive() - for instance. That said - I'm not opposed to extend the scope of the timeout to make it closer to the perceived timeout, which is what the test expect. 
If we do this maybe we could move `start` out of the `do` block  - which would make the computation of `timeoutLeft` simpler (we wouldn't need the `-=`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750438221

From dfuchs at openjdk.org  Mon Sep  9 15:14:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Sep 2024 15:14:10 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
Message-ID: <dxilMjYp5Qm7VRxChcq7GKq8SYoqlcAOTykIB3Jqlb8=.ebc515a6-b5ec-4467-b3fb-38512d799fe3@github.com>

On Mon, 9 Sep 2024 11:42:25 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - guard against possible integer value overflows
>  - make startTime a local variable

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 440:

> 438:                 InetSocketAddress target = new InetSocketAddress(server, port);
> 439:                 udpChannel.connect(target);
> 440:                 long pktTimeout = (timeout * (1L << retry));

Suggestion:

                // use 1L below to ensure conversion to long and avoid potential
                // integer overflow (timeout is an int) 
                long pktTimeout = (timeout * (1L << retry));

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 444:

> 442: 
> 443:                 // timeout remaining after successive 'blockingReceive()'
> 444:                 long timeoutLeft = Math.clamp(pktTimeout, 0, Integer.MAX_VALUE);

Suggestion:

                // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed
                long timeoutLeft = Math.clamp(pktTimeout, 0, Integer.MAX_VALUE);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750444825
PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750447201

From liach at openjdk.org  Mon Sep  9 15:18:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 15:18:10 GMT
Subject: RFR: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator [v2]
In-Reply-To: <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
 <dMUAhHE5lY5MxUjoUqJKBqon2NEJQyzjbMdYMDv6xS0=.2cd0dd0a-7d6e-40f0-a729-073a0b32ec41@github.com>
Message-ID: <EYoI_LsZgABUAmgnNj0_Vnfol21X3Q01qpkUWejKoSc=.b440aa6c-485c-43eb-a4ac-5c41ffc6caa0@github.com>

On Fri, 6 Sep 2024 19:55:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not try to classdata non-live lambda forms in pre-generation

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20896#issuecomment-2338396055

From liach at openjdk.org  Mon Sep  9 15:18:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 15:18:10 GMT
Subject: Integrated: 8339683: Simplify class data generation in
 InvokerBytecodeGenerator
In-Reply-To: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
References: <kQ-7IcX5J2I2v3r3sDziEO6cZuzLu-mYvRi2ZOb2UO4=.f5eefa1e-6cbb-4877-8bc3-7310e9b08d73@github.com>
Message-ID: <1tdLRELlUgGAd8207B1blYSc_1Slt3HR3ylPC_WaT30=.4e7fef5b-d35b-4a86-94aa-e6f9b5f5eeee@github.com>

On Fri, 6 Sep 2024 18:56:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Elide duplicate field CP entry creation, and reuse elements in the field CP entry for field generation.

This pull request has now been integrated.

Changeset: a9bb0433
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9bb04331df6788561921202cac73e35afbfe314
Stats:     70 lines in 2 files changed: 9 ins; 32 del; 29 mod

8339683: Simplify class data generation in InvokerBytecodeGenerator

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20896

From mcimadamore at openjdk.org  Mon Sep  9 15:33:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 15:33:44 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop spurious change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20914/files
  - new: https://git.openjdk.org/jdk/pull/20914/files/32389c43..4053014e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914

PR: https://git.openjdk.org/jdk/pull/20914

From mcimadamore at openjdk.org  Mon Sep  9 15:33:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 15:33:45 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>
Message-ID: <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com>

On Mon, 9 Sep 2024 15:30:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
>> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
>> 
>> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
>> 
>> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious change

src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 128:

> 126:     static {
> 127:         registerNatives();
> 128:         isLoaded0(0, 0, 0);

This spurious line was added for debugging reasons in a previous PR - it should have been removed. Doing it now. This is probably the cause of https://bugs.openjdk.org/browse/JDK-8339780

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750481339

From liach at openjdk.org  Mon Sep  9 15:38:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 15:38:07 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v11]
In-Reply-To: <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
Message-ID: <-doRMfjyzUYLoMY2GITATKDhxU3W48Rv6yk7jrkG0s0=.5e8b631b-a529-46a3-a968-adda9707908f@github.com>

On Mon, 9 Sep 2024 01:53:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @cl4es

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20675#pullrequestreview-2290280218

From mdoerr at openjdk.org  Mon Sep  9 15:41:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 9 Sep 2024 15:41:06 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>
 <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com>
Message-ID: <sB7Lv4H0LNWAwT92PlWtXBPAY9o3g9jrXdtHnfnOBFI=.0b26da6d-2be1-4f4b-ab83-f18ee1e605a2@github.com>

On Mon, 9 Sep 2024 15:30:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop spurious change
>
> src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 128:
> 
>> 126:     static {
>> 127:         registerNatives();
>> 128:         isLoaded0(0, 0, 0);
> 
> This spurious line was added for debugging reasons in a previous PR - it should have been removed. Doing it now. This is probably the cause of https://bugs.openjdk.org/browse/JDK-8339780

Yes. Thanks for fixing it! Maybe you can add that issue to this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750492934

From psandoz at openjdk.org  Mon Sep  9 15:52:05 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 9 Sep 2024 15:52:05 GMT
Subject: RFR: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and
 laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits
In-Reply-To: <k8vB49WnWpfRLYx26KCscdKLwXeLvQFn6HQMXrZ0-nk=.fa626dca-552f-4133-8152-fda8057a952a@github.com>
References: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
 <k8vB49WnWpfRLYx26KCscdKLwXeLvQFn6HQMXrZ0-nk=.fa626dca-552f-4133-8152-fda8057a952a@github.com>
Message-ID: <Hm1H6GX-Bg1MK83WMBD_hmYREs5cHMmRQsET_eo9fXA=.9f12dd3a-d385-4358-8662-9cc670861d0f@github.com>

On Sat, 7 Sep 2024 04:47:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes an issue where we mistakenly use `Double::doubleToLongBits` in `DoubleXXXVector::withLaneHelper` and `DoubleXXXVector::laneHelper`. We should use the raw bit version instead.
>> 
>> Please kindly review, thanks very much.
>
> Hello @merykitty, there are several files in this PR with just copyright year updates and no other change. Is that intentional?

> @jaikiran All the `YYYXXXVector.java` files are generated from `X-VectorBits.java.template`, so if I change some of them all the others will get their copyright year updated as well.

Yes its an unfortunately side-effect of generation from template files. (There is a issue/task to integrate this generation into the build system, but given we are incubating there is less urgency to do this.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20895#issuecomment-2338478224

From duke at openjdk.org  Mon Sep  9 15:57:11 2024
From: duke at openjdk.org (duke)
Date: Mon, 9 Sep 2024 15:57:11 GMT
Subject: Withdrawn: 8225763: Inflater and Deflater should implement
 AutoCloseable
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <lJo5PcJCsaba-ftPHZK_K_bxI7RwSNoyPbzt7_LKYYU=.62487f92-c1a2-4083-aab8-e1daababb84c@github.com>

On Wed, 12 Jun 2024 10:45:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19675

From naoto at openjdk.org  Mon Sep  9 16:05:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Sep 2024 16:05:04 GMT
Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3]
In-Reply-To: <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
 <f5CQ0emOTmSwS-umHubVxphH8UKflxv9IpNcklMlf80=.fb5e1880-6308-413d-9c0b-135fd387136f@github.com>
Message-ID: <1ctZ88OHCV_abfZ3lL4ae4accAhnqAL8ue_P-f_Nzt0=.d7eb0c9f-6671-4c14-993e-81957602f643@github.com>

On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strictly conforming to the spec

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20893#issuecomment-2338507731

From naoto at openjdk.org  Mon Sep  9 16:08:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Sep 2024 16:08:08 GMT
Subject: Integrated: 8339644: Improve parsing of Day/Month in tzdata rules
In-Reply-To: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
References: <B-plCrQNtaqvV716xkbOPM7W2dNCeEzWJ53_NaB3VYI=.f9a7e638-f902-4f76-bb52-813e3968add7@github.com>
Message-ID: <9SLWFkmkkPGEBwR1Q4RJrxVFGdimaurZcS9SeMsTgO4=.fd678df3-d08b-4201-9e00-fc8899e46ac5@github.com>

On Fri, 6 Sep 2024 17:40:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK.

This pull request has now been integrated.

Changeset: 86a2f9c7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86a2f9c7dcb6585cabf03c0940511d11560e85b7
Stats:     83 lines in 3 files changed: 23 ins; 26 del; 34 mod

8339644: Improve parsing of Day/Month in tzdata rules

Reviewed-by: jlu, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/20893

From smarks at openjdk.org  Mon Sep  9 16:15:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 9 Sep 2024 16:15:04 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
 <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
Message-ID: <IrKH9LoQfUxwjyOgctY0bXsvv9JKLchGYMEwgXR4U9c=.84640b4b-3502-4737-89a5-24d6860ae57a@github.com>

On Mon, 9 Sep 2024 05:01:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 82:
>> 
>>> 80:         PhantomReference<Object> ref = new PhantomReference<>(obj, queue);
>>> 81:         Reference.reachabilityFence(obj);
>>> 82:         obj = null;
>> 
>> You're right to question the utility of calling reachabilityFence(obj) after obj has been nulled out. But I'm still questioning the utility of calling RF(obj) at all. We don't care when obj is determined to be unreachable; what we care about is that the GC has done some reference processing. Seems to me we can simplify the above lines to
>> 
>>     PhantomReference<Object> ref = new PhantomReference<>(new Object(), queue);
>> 
>> and get rid of the local variable obj entirely.
>
> The reason for the explicit reference and RF, as I recall, is to guard against the allocation of the new object being elided entirely, with the `PhantomReference` constructor being passed null (or itself being elided) and no reference processing ever actually happening.

@dholmes-ora Is this really possible? The `obj` ref is passed to the PhantomReference constructor, which stores it in a field, the constructed PhantomReference is returned, and it's then used in a reachabilityFence call below. So `obj` should remain reachable the entire time, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1750545860

From aefimov at openjdk.org  Mon Sep  9 16:16:49 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 16:16:49 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v3]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <b4fkP999zm5d5tlyNIceQ0XCb2tDblW9Lv1kBI_q-JI=.6a2edb0d-f826-4cbe-930d-38e4e0fa65c1@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Update src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/30f883b8..9abcfb25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From smarks at openjdk.org  Mon Sep  9 16:28:06 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 9 Sep 2024 16:28:06 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <IrKH9LoQfUxwjyOgctY0bXsvv9JKLchGYMEwgXR4U9c=.84640b4b-3502-4737-89a5-24d6860ae57a@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
 <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
 <IrKH9LoQfUxwjyOgctY0bXsvv9JKLchGYMEwgXR4U9c=.84640b4b-3502-4737-89a5-24d6860ae57a@github.com>
Message-ID: <MxYi4-yIihxeKsgF0qlseZA03IW5z4hg-aREv5CBCNM=.d8991dc0-25a6-4c0c-90be-00f0346b61b2@github.com>

On Mon, 9 Sep 2024 16:12:02 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The reason for the explicit reference and RF, as I recall, is to guard against the allocation of the new object being elided entirely, with the `PhantomReference` constructor being passed null (or itself being elided) and no reference processing ever actually happening.
>
> @dholmes-ora Is this really possible? The `obj` ref is passed to the PhantomReference constructor, which stores it in a field, the constructed PhantomReference is returned, and it's then used in a reachabilityFence call below. So `obj` should remain reachable the entire time, right?

(As an aside, I wasn't able to determine what any of the Reference classes do if they're created with a null reference. Possibly a spec bug?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1750564209

From aefimov at openjdk.org  Mon Sep  9 16:31:23 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 16:31:23 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v4]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <LuDcX0UBkmfxfG1CQOnz2j2QrwjeMiRA0cWpyAzNrtY=.310b7cd2-2e03-4f24-aa11-2dddd6db16d5@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  fix trailing white-space in a comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/9abcfb25..eb2b2cd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From djelinski at openjdk.org  Mon Sep  9 17:13:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 9 Sep 2024 17:13:05 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v4]
In-Reply-To: <RVEg2H8qkzN9o0mhWIRwA5obV5-3GiGx80KWyG6UdgM=.e9acae85-0bca-4fbe-aef2-9b16f93a9628@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <RVEg2H8qkzN9o0mhWIRwA5obV5-3GiGx80KWyG6UdgM=.e9acae85-0bca-4fbe-aef2-9b16f93a9628@github.com>
Message-ID: <1gF2_D9gn60QlQRarZmvpScv7YxCi6MNM09vbDNdFMU=.9760607c-c25d-460e-ac2b-619c2a9c05f4@github.com>

On Fri, 6 Sep 2024 17:47:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Revised class level doc of File

Looks like a good improvement.

Does `File.exists` check the existence of the link target?

Can we copy this part of package-summary too?
> ...and operations on symbolic links are automatically redirected to the <em>target</em>

without it, it's not clear what `transparent` means.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2338641576

From aefimov at openjdk.org  Mon Sep  9 17:18:07 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 17:18:07 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <8arNF1zT2CeGesIVagTy5WcJ5303piCVad9Natbsczg=.d4ce9430-0171-4428-aaad-99974b26a7ed@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
 <Oyvs4mAve9Ig-HV-BB-2CoToeUJ2t1Ys_oMg4LNn0uE=.0af35357-4da7-4f6e-a980-83ce9b29b2b1@github.com>
 <yw8BCiwm648UHd2LqQNqxaibTkKLaLt_VW_wX7vrwik=.900bd11b-436d-4acc-ad5e-5ec302a96f3a@github.com>
 <8arNF1zT2CeGesIVagTy5WcJ5303piCVad9Natbsczg=.d4ce9430-0171-4428-aaad-99974b26a7ed@github.com>
Message-ID: <pEKHrYwEYfbm4cAfISkqmtqGsV68G2cJLnUISLWDxPg=.89a2b486-60f2-4fae-8e11-169c44a4d34a@github.com>

On Mon, 9 Sep 2024 15:03:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sounds like a right thing to do:  measuring time in the loop should give us better estimation on time DNS client spends waiting on the response after submiting a query (that's how environment property value is defined in [javadoc here](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html)).
>> I've tried to move `start` and `end` like:
>> 
>>                  do {
>> +                    long start = System.nanoTime();
>> <....>
>> -                    long start = System.nanoTime();
>>                      gotData = blockingReceive(udpChannel, ipkt, timeoutLeft);
>> -                    long end = System.nanoTime();
>> <...>
>> +                    long end = System.nanoTime();
>>                      long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end - start);
>> 
>> As a result the tests showed that the timeout happened with a bit better precision (10th of milliseconds).
>> I will run more tests and incorporate the suggestions. Thank you.
>
> I have been wondering why the timeout was measured in this way. My explanation was that the original author of the API (duke? ;-) ) wanted to measure "actual timeout" (time actually spent waiting for a packet) as opposed to perceived timeout (time the caller spent waiting). Rationale might have been to exclude potential time spent waiting for a lock before entering receive() - for instance. That said - I'm not opposed to extend the scope of the timeout to make it closer to the perceived timeout, which is what the test expect. 
> If we do this maybe we could move `start` out of the `do` block  - which would make the computation of `timeoutLeft` simpler (we wouldn't need the `-=`).

I think that "the perceived timeout" described by you above is closer to the following description of the timeout environment property:
```The provider submits a query to a DNS server and waits for a response to arrive within a timeout period (1 second by default)```
And the query is submitted to a DNS server right before entrering the while loop.
I will apply the suggested simplification of the timeout left now, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750628602

From swen at openjdk.org  Mon Sep  9 17:20:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 9 Sep 2024 17:20:44 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v6]
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <9ls0kBdzdPcFkhX7afFDPyt77Td9vF76d0zhH6qAuSw=.64bc9876-c3a2-43b9-ba2d-3f170f7d6956@github.com>

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  more 2 arguments simple concat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20726/files
  - new: https://git.openjdk.org/jdk/pull/20726/files/f63e6a7f..ed070af2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=04-05

  Stats: 19 lines in 1 file changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From zzambers at openjdk.org  Mon Sep  9 17:33:10 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Mon, 9 Sep 2024 17:33:10 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v9]
In-Reply-To: <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
Message-ID: <df3F3nSt_UChIFIyrVjx8dNqvQ3OvIRwhWXcdb8Fy7g=.1afb4075-06a0-4665-b944-772d5c0d4edf@github.com>

On Wed, 4 Sep 2024 17:46:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
>> - [x] GHA
>
> Severin Gehwolf 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:
> 
>  - Adapt JDK-8339148
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>  - Add root check for SystemdMemoryAwarenessTest.java
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3d582133...30f32d22

I have done some testing on RHELs (build with changes from this PR + other 2 container PRs applied):
**RHEL-8** (cgroup1/non-root)
- test was skipped correctly

**RHEL-9** (cgroup2/non-root)
- I saw failure of `active_processor_count` check.
- after investigation, I have found, that `cpu` cgroup controller is not delegated to `user at 1000.service` (and children) on rhel-9 (unlike in e.g. fedora) it only had `memory pids` (btw. available controllers at given "level" are listed in `cgroup.controllers` file in cgroups v2)
- when I modified `user at .service` to also delegate cpu controller, test passed

Apart from issue with check for `active_processor_count` on RHEL-9/non-root, it looks good. However I don't know how to easily fix issue with `active_processor_count` check. Maybe check could be skipped for non-root. (Work-around is to modify system configuration.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2338674577

From zzambers at openjdk.org  Mon Sep  9 17:56:10 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Mon, 9 Sep 2024 17:56:10 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v6]
In-Reply-To: <zcnAOfImTlUcaw_Pc2eCr6_5zJvRp4HfNiZ5wHx6B8s=.54bcf23f-f79c-4ded-b692-4589f416b061@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <zcnAOfImTlUcaw_Pc2eCr6_5zJvRp4HfNiZ5wHx6B8s=.54bcf23f-f79c-4ded-b692-4589f416b061@github.com>
Message-ID: <8gUmlAm4i141LkybkwZbgfsAQhqAcpOLVv11q0RU6rw=.c6426230-e575-442d-9384-a5d1042b3887@github.com>

On Thu, 5 Sep 2024 13:25:17 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 proposed 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Add JVM_HostActiveProcessorCount using JVM api
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Adjust test and fix code to return lowest hierarchical limit
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Add root check for SystemdMemoryAwarenessTest
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - 8336881: [Linux] Support for hierarchical limits for Metrics

When looking at https://github.com/openjdk/jdk/pull/19530 and I have done build also including current changeset from this PR and from https://github.com/openjdk/jdk/pull/20646. I have tried to run container tests and seen some failures (RHEL-9):

**CgroupSubsystemCpuControllerTest:**

org.opentest4j.AssertionFailedError: expected: <2> but was: <5>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
	at CgroupSubsystemCpuControllerTest.adjustedLimitLowerInHierarchy(CgroupSubsystemCpuControllerTest.java:92)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)


**CgroupSubsystemMemoryControllerTest:**

org.opentest4j.AssertionFailedError: expected: </> but was: </a/b/c/d>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
	at CgroupSubsystemMemoryControllerTest.adjustedLimitAtRoot(CgroupSubsystemMemoryControllerTest.java:90)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2338729475

From darcy at openjdk.org  Mon Sep  9 18:42:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Sep 2024 18:42:16 GMT
Subject: RFR: 8339789: Use index and definition tags in AnnotatedElement
Message-ID: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>

Use index and definition tags in AnnotatedElement.

-------------

Commit messages:
 - JDK-8339789: Use index and definition tags in AnnotatedElement

Changes: https://git.openjdk.org/jdk/pull/20919/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20919&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339789
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20919/head:pull/20919

PR: https://git.openjdk.org/jdk/pull/20919

From alanb at openjdk.org  Mon Sep  9 18:52:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Sep 2024 18:52:05 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <HZIkgWxq3qbji5g5CcwUcrOrGyMycwv2R2JdD5Usvxc=.916fb76b-626e-4bbf-bccd-6b86a752ac15@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <HZIkgWxq3qbji5g5CcwUcrOrGyMycwv2R2JdD5Usvxc=.916fb76b-626e-4bbf-bccd-6b86a752ac15@github.com>
Message-ID: <QyOLsjqccBZKhXbU8mLxAhJESoXooDSGsXzUikFBGF4=.06845b05-2447-4531-9b1b-e613c3b9bc81@github.com>

On Mon, 9 Sep 2024 12:59:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop spurious change
>
> src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java line 9:
> 
>> 7:  * This allows to avoid pesky initialization issues in the middle of memory mapped scoped methods.
>> 8:  */
>> 9: public interface MappedMemoryUtilsProxy {
> 
> We should probably try to consolidate this and `UmapperProxy` - I think it can be done, but it requires deeper surgery than I was willing to do in this PR.

Although this proxy class may be temporarily, I'll think you'll need to put a copyright header on it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750760987

From jjg at openjdk.org  Mon Sep  9 18:53:08 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 9 Sep 2024 18:53:08 GMT
Subject: RFR: 8339789: Use index and definition tags in AnnotatedElement
In-Reply-To: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
References: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
Message-ID: <h24EZ9hh6H5Z4VZ6Tw_KCuxQUZgUPxx5fCH5GYXhz0c=.a8d53e38-69f1-4d6d-b7cb-7be3c86e77f0@github.com>

On Mon, 9 Sep 2024 18:37:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use index and definition tags in AnnotatedElement.

OK.

As a subsidiary follow-up, one might ask whether `{@index...}` should implicitly include `<dfn>` tags in its output.

-------------

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20919#pullrequestreview-2290700260

From bpb at openjdk.org  Mon Sep  9 19:02:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Sep 2024 19:02:03 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v4]
In-Reply-To: <1gF2_D9gn60QlQRarZmvpScv7YxCi6MNM09vbDNdFMU=.9760607c-c25d-460e-ac2b-619c2a9c05f4@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <RVEg2H8qkzN9o0mhWIRwA5obV5-3GiGx80KWyG6UdgM=.e9acae85-0bca-4fbe-aef2-9b16f93a9628@github.com>
 <1gF2_D9gn60QlQRarZmvpScv7YxCi6MNM09vbDNdFMU=.9760607c-c25d-460e-ac2b-619c2a9c05f4@github.com>
Message-ID: <8NbiOSbXcxRjCPCIhItPqKlNJcWgPMjI8rhZRoNmoMk=.a44492cd-8bc1-4322-aa94-aa5311d24a86@github.com>

On Mon, 9 Sep 2024 17:10:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Does `File.exists` check the existence of the link target?

Yes. Verified on both Unix (macOS) and Windows 11.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2338863163

From bpb at openjdk.org  Mon Sep  9 19:22:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Sep 2024 19:22:19 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v5]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Replace "transparent" with more explicit verbiage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/9737dfc5..584742e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=03-04

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From bpb at openjdk.org  Mon Sep  9 19:22:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Sep 2024 19:22:19 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v4]
In-Reply-To: <RVEg2H8qkzN9o0mhWIRwA5obV5-3GiGx80KWyG6UdgM=.e9acae85-0bca-4fbe-aef2-9b16f93a9628@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <RVEg2H8qkzN9o0mhWIRwA5obV5-3GiGx80KWyG6UdgM=.e9acae85-0bca-4fbe-aef2-9b16f93a9628@github.com>
Message-ID: <w-UfRfMaAnEsLAChLSkJqg4XxiB9DMvB6bsOFRDIKcA=.6ba887c6-fcfd-4af4-be81-507e72cbf06c@github.com>

On Fri, 6 Sep 2024 17:47:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Revised class level doc of File

> Can we copy this part of package-summary too?
> 
> > ...and operations on symbolic links are automatically redirected to the _target_
> 
> without it, it's not clear what `transparent` means.

Please see 584742e.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2338898271

From duke at openjdk.org  Mon Sep  9 20:27:47 2024
From: duke at openjdk.org (fitzsim)
Date: Mon, 9 Sep 2024 20:27:47 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v4]
In-Reply-To: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
Message-ID: <Gn8hZZh6sOzHO2mttoFY9einys2nCWrpew9NPH2Ltvs=.60ba4237-9ffd-438e-bab7-ee9653a3731f@github.com>

> 8334048: -Xbootclasspath can not read some ZIP64 zip files

fitzsim has updated the pull request incrementally with two additional commits since the last revision:

 - BootClassPathZipFileTest: Use test.classes directory for test ZIPs
 - BootClassPathZipFileTest, BootClassPathZipFileCreator: Move to test/jdk/java/util/zip/ZipFile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19678/files
  - new: https://git.openjdk.org/jdk/pull/19678/files/29090779..27dc9d69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=02-03

  Stats: 119 lines in 3 files changed: 62 ins; 56 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19678/head:pull/19678

PR: https://git.openjdk.org/jdk/pull/19678

From mcimadamore at openjdk.org  Mon Sep  9 21:11:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 21:11:32 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v3]
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <AdHWmMpeoEX2Unu8lDHj_bvR_5Gsuj_qA-cL8gIP65I=.114a8101-cd97-4473-b3ce-bb27a4c21c8c@github.com>

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20914/files
  - new: https://git.openjdk.org/jdk/pull/20914/files/4053014e..80b61d15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=01-02

  Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914

PR: https://git.openjdk.org/jdk/pull/20914

From bpb at openjdk.org  Mon Sep  9 21:37:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Sep 2024 21:37:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <U2yUCoL3e_DLuzGOLguyVKh5wXbRiCjBkV2KC8NQgfY=.203e73ce-cb4d-40e6-ac69-ad2359667086@github.com>

On Fri, 9 Aug 2024 17:59:12 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

continue;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2339193692

From dholmes at openjdk.org  Mon Sep  9 22:15:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Sep 2024 22:15:11 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <MxYi4-yIihxeKsgF0qlseZA03IW5z4hg-aREv5CBCNM=.d8991dc0-25a6-4c0c-90be-00f0346b61b2@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
 <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
 <IrKH9LoQfUxwjyOgctY0bXsvv9JKLchGYMEwgXR4U9c=.84640b4b-3502-4737-89a5-24d6860ae57a@github.com>
 <MxYi4-yIihxeKsgF0qlseZA03IW5z4hg-aREv5CBCNM=.d8991dc0-25a6-4c0c-90be-00f0346b61b2@github.com>
Message-ID: <9_8XSOrz70Pz5qqOId3fK0RL0C-eAvaIxYes58YdjKM=.3344dbea-4cc7-474f-89df-a94ebf762785@github.com>

On Mon, 9 Sep 2024 16:25:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @dholmes-ora Is this really possible? The `obj` ref is passed to the PhantomReference constructor, which stores it in a field, the constructed PhantomReference is returned, and it's then used in a reachabilityFence call below. So `obj` should remain reachable the entire time, right?
>
> (As an aside, I wasn't able to determine what any of the Reference classes do if they're created with a null reference. Possibly a spec bug?)

@stuart-marks  My recollection, which I can't confirm is that this pattern was discussed internally and there was a lot of uncertainty about what was actually needed. Interestingly there was zero discussion of this in the actual PR that added it - https://github.com/openjdk/jdk/pull/8979

Thinking it through now, I tend to agree with you that the RF for `ref` suffices to prevent `obj` from being elided

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1751000575

From aefimov at openjdk.org  Mon Sep  9 22:29:23 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 22:29:23 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Measure time the caller spent waiting. Simplify timeoutLeft computation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/eb2b2cd7..4d33d05b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=03-04

  Stats: 11 lines in 1 file changed: 2 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From aefimov at openjdk.org  Mon Sep  9 22:34:04 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 9 Sep 2024 22:34:04 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v2]
In-Reply-To: <pEKHrYwEYfbm4cAfISkqmtqGsV68G2cJLnUISLWDxPg=.89a2b486-60f2-4fae-8e11-169c44a4d34a@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <D7DOAVV1snTZ3UMAixUFZNTWyHGceQvMYBHXC9tbv0o=.1b6ca97f-9864-4965-a04a-458a09da9e21@github.com>
 <Oyvs4mAve9Ig-HV-BB-2CoToeUJ2t1Ys_oMg4LNn0uE=.0af35357-4da7-4f6e-a980-83ce9b29b2b1@github.com>
 <yw8BCiwm648UHd2LqQNqxaibTkKLaLt_VW_wX7vrwik=.900bd11b-436d-4acc-ad5e-5ec302a96f3a@github.com>
 <8arNF1zT2CeGesIVagTy5WcJ5303piCVad9Natbsczg=.d4ce9430-0171-4428-aaad-99974b26a7ed@github.com>
 <pEKHrYwEYfbm4cAfISkqmtqGsV68G2cJLnUISLWDxPg=.89a2b486-60f2-4fae-8e11-169c44a4d34a@github.com>
Message-ID: <tYW1hSynWDdcah1eez1crTgKdaeRpKYcTCZ6IK3NBQE=.5e60e145-8260-4b38-90d8-a741e4ab2819@github.com>

On Mon, 9 Sep 2024 17:15:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> I have been wondering why the timeout was measured in this way. My explanation was that the original author of the API (duke? ;-) ) wanted to measure "actual timeout" (time actually spent waiting for a packet) as opposed to perceived timeout (time the caller spent waiting). Rationale might have been to exclude potential time spent waiting for a lock before entering receive() - for instance. That said - I'm not opposed to extend the scope of the timeout to make it closer to the perceived timeout, which is what the test expect. 
>> If we do this maybe we could move `start` out of the `do` block  - which would make the computation of `timeoutLeft` simpler (we wouldn't need the `-=`).
>
> I think that "the perceived timeout" described by you above is closer to the following description of the timeout environment property:
> ```The provider submits a query to a DNS server and waits for a response to arrive within a timeout period (1 second by default)```
> And the query is submitted to a DNS server right before entering the while loop.
> I will apply the suggested simplification of the timeout left now, thanks.

The code now measures "the perceived timeout": [4d33d05](https://github.com/openjdk/jdk/pull/20892/commits/4d33d05b111f38a418dac57587236465f2359f8c)
The timeout JNDI/DNS tests seem to be stable and a bit more accurate across multiple runs with the latest changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1751014669

From redestad at openjdk.org  Mon Sep  9 22:59:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 22:59:32 GMT
Subject: RFR: 8339799: Reduce work done in j.l.invoke bytecode generators
Message-ID: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>

Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
- Define `ClassEntry` early, use it when profitable (there are some warts in the API where using `ce.name(), ce.type()` in a few places means we drop the link to the `ClassDesc` which will then be re-spun in later - should be revisited)
- Use `mh.invokeBasic()` for zero-arg non-capturing lambda constructor calls(!) 
- Narrow name validation to the name passed in
- We were calling `classDesc` twice per factoryType argument, refactored to reuse `argDescs`. 

Interpreter instrumentation sees 1.5% less bytecode executed on netty startup tests, -2.5% on minimal lambda test. Part of the https://bugs.openjdk.org/browse/JDK-8338542 ClassFile API startup work.

-------------

Commit messages:
 - Fix comment
 - Use invokeBasic for non-capturing lambdas, other minor opts
 - Improve reuse of ClassEntry in j.l.invoke class builders

Changes: https://git.openjdk.org/jdk/pull/20925/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20925&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339799
  Stats: 26 lines in 2 files changed: 5 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20925/head:pull/20925

PR: https://git.openjdk.org/jdk/pull/20925

From liach at openjdk.org  Mon Sep  9 23:30:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 23:30:04 GMT
Subject: RFR: 8339799: Reduce work done in j.l.invoke bytecode generators
In-Reply-To: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
References: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
Message-ID: <8pGbKpwcO2jv_Q8URN1qGNvr9SnPfS74zP1ZnFnYs8c=.31658cce-6313-49ab-b4e7-c2f2ca6bae9c@github.com>

On Mon, 9 Sep 2024 22:53:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
> - Define `ClassEntry` early, use it when profitable (there are some warts in the API where using `ce.name(), ce.type()` in a few places means we drop the link to the `ClassDesc` which will then be re-spun in later - should be revisited)
> - Use `mh.invokeBasic()` for zero-arg non-capturing lambda constructor calls(!) 
> - Narrow name validation to the name passed in
> - We were calling `classDesc` twice per factoryType argument, refactored to reuse `argDescs`. 
> 
> Interpreter instrumentation sees 1.5% less bytecode executed on netty startup tests, -2.5% on minimal lambda test. Part of the https://bugs.openjdk.org/browse/JDK-8338542 ClassFile API startup work.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 101:

> 99:     private final String lambdaClassName;            // Generated name for the generated class "X$$Lambda$1"
> 100:     private final ConstantPoolBuilder pool = ConstantPoolBuilder.of();
> 101:     private final ClassEntry lambdaClassEntry;       // Class entry for the generated class "X$$Lambda$1"

Does this improvement go away if remove this change to use explicit class entries? I think I can do some constant pool work to improve ClassEntry retrieval from ClassDesc. Something like #20667, but I will try move the hash to ClassEntry to enforce ClassDesc primacy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20925#discussion_r1751051598

From duke at openjdk.org  Mon Sep  9 23:46:06 2024
From: duke at openjdk.org (fitzsim)
Date: Mon, 9 Sep 2024 23:46:06 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v4]
In-Reply-To: <Gn8hZZh6sOzHO2mttoFY9einys2nCWrpew9NPH2Ltvs=.60ba4237-9ffd-438e-bab7-ee9653a3731f@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <Gn8hZZh6sOzHO2mttoFY9einys2nCWrpew9NPH2Ltvs=.60ba4237-9ffd-438e-bab7-ee9653a3731f@github.com>
Message-ID: <N5Ztdj9jf2GmhTm8Ejpdc5zPvFVCocPEnXXm6FLFYJA=.92279f5b-2567-464e-b374-0b7a4b1f657e@github.com>

On Mon, 9 Sep 2024 20:27:47 GMT, fitzsim <duke at openjdk.org> wrote:

>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - BootClassPathZipFileTest: Use test.classes directory for test ZIPs
>  - BootClassPathZipFileTest, BootClassPathZipFileCreator: Move to test/jdk/java/util/zip/ZipFile

I pushed the review suggestions.  There were two GitHub Actions failures on `macos-aarch64`, but they look to be occurrences of this existing bug: https://bugs.openjdk.org/browse/JDK-8247940.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2339338945

From redestad at openjdk.org  Mon Sep  9 23:57:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Sep 2024 23:57:32 GMT
Subject: RFR: 8339800: Prefer invokeBasic in BootstrapMethodInvokers
Message-ID: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>

Switching to `invokeBasic` for type-check invokes in `BootstrapMethodInvokers` instead of `invokeExact` avoids some `MethodHandleNatives.linkMethod` calls during bootstrap. This brings a tiny but measurable once-per-bootstrap method win. Both before and after we lean on the static casts in BootstrapMethodInvokers to sanitize against type mismatches.

-------------

Commit messages:
 - Prefer invokeBasic in BootstrapMethodInvokers

Changes: https://git.openjdk.org/jdk/pull/20926/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339800
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20926/head:pull/20926

PR: https://git.openjdk.org/jdk/pull/20926

From jvernee at openjdk.org  Tue Sep 10 00:02:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Sep 2024 00:02:04 GMT
Subject: RFR: 8339800: Prefer invokeBasic in BootstrapMethodInvokers
In-Reply-To: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>
References: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>
Message-ID: <T6I88OtnGlRudJhQm17kW3Eo_yP-Qbccwyz5FtTLoew=.fe3637a6-adaf-42bc-b379-9e5b42cb0ac6@github.com>

On Mon, 9 Sep 2024 23:52:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Switching to `invokeBasic` for type-check invokes in `BootstrapMethodInvokers` instead of `invokeExact` avoids some `MethodHandleNatives.linkMethod` calls during bootstrap. This brings a tiny but measurable once-per-bootstrap method win. Both before and after we lean on the static casts in BootstrapMethodInvokers to sanitize against type mismatches.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20926#pullrequestreview-2291133181

From redestad at openjdk.org  Tue Sep 10 00:43:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 00:43:09 GMT
Subject: RFR: 8339799: Reduce work done in j.l.invoke bytecode generators
In-Reply-To: <8pGbKpwcO2jv_Q8URN1qGNvr9SnPfS74zP1ZnFnYs8c=.31658cce-6313-49ab-b4e7-c2f2ca6bae9c@github.com>
References: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
 <8pGbKpwcO2jv_Q8URN1qGNvr9SnPfS74zP1ZnFnYs8c=.31658cce-6313-49ab-b4e7-c2f2ca6bae9c@github.com>
Message-ID: <Txjhr52R9xuqzP3oAbh3veX3l0ptZ1lLNKnBhwYXw7A=.debba490-7bd1-4f1c-8613-52af0b603b1c@github.com>

On Mon, 9 Sep 2024 23:27:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
>> - Define `ClassEntry` early, use it when profitable (there are some warts in the API where using `ce.name(), ce.type()` in a few places means we drop the link to the `ClassDesc` which will then be re-spun in later - should be revisited)
>> - Use `mh.invokeBasic()` for zero-arg non-capturing lambda constructor calls(!) 
>> - Narrow name validation to the name passed in
>> - We were calling `classDesc` twice per factoryType argument, refactored to reuse `argDescs`. 
>> 
>> Interpreter instrumentation sees 1.5% less bytecode executed on netty startup tests, -2.5% on minimal lambda test. Part of the https://bugs.openjdk.org/browse/JDK-8338542 ClassFile API startup work.
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 101:
> 
>> 99:     private final String lambdaClassName;            // Generated name for the generated class "X$$Lambda$1"
>> 100:     private final ConstantPoolBuilder pool = ConstantPoolBuilder.of();
>> 101:     private final ClassEntry lambdaClassEntry;       // Class entry for the generated class "X$$Lambda$1"
> 
> Does this improvement go away if remove this change to use explicit class entries? I think I can do some constant pool work to improve ClassEntry retrieval from ClassDesc. Something like #20667, but I will try move the hash to ClassEntry to enforce ClassDesc primacy.

When experimenting with this all the changes in this PR individually moved the needle in the right direction. If you have doubts about this facet in particular I can split it out and we can re-evaluate it together with #20667.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20925#discussion_r1751094170

From swen at openjdk.org  Tue Sep 10 00:51:04 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 10 Sep 2024 00:51:04 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v6]
In-Reply-To: <w3LViqepvmgpsQMfN4dT8NqviAgZapy00mXAX_hOwMg=.f86a5131-b0cd-4a74-ad42-6f0acf9282a0@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <TCOE5PqhKOgQx-Se93mk7kNae6NDHw9Q1tFlo81uGQ0=.98ee7e83-68a2-49a8-85d0-91fc0edaf7c3@github.com>
 <slFOI2sHX7qoL55uXDjNnPjXylA-q_LMCAMuW5Ortuk=.6c6fb8ea-f7c0-4dfe-8910-8515e3190c01@github.com>
 <w3LViqepvmgpsQMfN4dT8NqviAgZapy00mXAX_hOwMg=.f86a5131-b0cd-4a74-ad42-6f0acf9282a0@github.com>
Message-ID: <xAuS514sC8k3a1RsS4Bv_we9nNKXMfviPuo-qObjEPg=.8756b95e-6da5-4eb8-ae75-68a7fca49e36@github.com>

On Sun, 8 Sep 2024 16:37:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> String concatenation is required in many places in java.lang. These static concat methods will be used instead of "+", so null value processing is added. This is also the motivation for using static concat methods instead of Concat1.
>
> I don't think replacing a lot of concatenations in java.base with `SCH.concat` is very appealing and needs to be motivated by a substantial performance advantage. And for the places where it's motivated we can make sure to sanitize and handle `null` arguments.

Yes, we shouldn't pay for things we don't need. I added null value handling to the parameters in SCF and removed it in SCH.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1751099693

From jpai at openjdk.org  Tue Sep 10 04:36:42 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 04:36:42 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v10]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 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
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - merge latest from master branch
 - ... and 10 more: https://git.openjdk.org/jdk/compare/56387a09...129375da

-------------

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=09
  Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

PR: https://git.openjdk.org/jdk/pull/2752

From kbarrett at openjdk.org  Tue Sep 10 05:05:10 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Sep 2024 05:05:10 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <t9D3sem9FpIEv_EBlBPQLeg8k9xq80f5gyq2Vh2acMY=.bfd581fb-652d-4e8c-94ea-693922a30a88@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
 <t9D3sem9FpIEv_EBlBPQLeg8k9xq80f5gyq2Vh2acMY=.bfd581fb-652d-4e8c-94ea-693922a30a88@github.com>
Message-ID: <Xnk7lr8Rn-8KOVWvtzgfjr7WWth5rlYcx_GwZ94tVAo=.30e9fd28-52d8-4b67-9329-e62a0452a511@github.com>

On Mon, 9 Sep 2024 14:40:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 102:
>> 
>>> 100:             }
>>> 101:         }
>>> 102:         Reference.reachabilityFence(ref);
>> 
>> I think everything from the creation of ref to the line above needs to enclosed in a try-statement, with the finally-clause including RF(ref).
>
> Arguably the same might also apply to the other call to reachability fence: that is - we might need two try-finally to keep things by-the-book?

I don't see a requirement for any try-finally's here, since I don't care about the queue/ref/referent/enqueuing
for any exits other than running to the end of the function.  Adding some might make the code less fragile
against future changes, but adds clutter that might never provide any benefit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1751250311

From kbarrett at openjdk.org  Tue Sep 10 05:05:08 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Sep 2024 05:05:08 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
Message-ID: <Jix0rcmvgncWHyS5x2_wJ2-NGzW70_47LyD-wjn3ie4=.50bb307b-b225-4b21-90ae-92a3abd48113@github.com>

On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
> 
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
> 
> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
> 
> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
> 
> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
> 
> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

The reachability changes look good to me.

The sketchy timeout handling mentioned by @stuart-marks seems to me to be out
of scope for this issue.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20898#pullrequestreview-2291357966

From kbarrett at openjdk.org  Tue Sep 10 05:05:09 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Sep 2024 05:05:09 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <MxYi4-yIihxeKsgF0qlseZA03IW5z4hg-aREv5CBCNM=.d8991dc0-25a6-4c0c-90be-00f0346b61b2@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <LIAFBorwSZV4vA6DA81040VJRoFCn7yLYEQhL6yYVHQ=.6e49da6b-41b4-4013-af46-d402d7bcbe26@github.com>
 <WtwbCMqN2s-XhfqxGUXoVgpiHfhiLY04kCbZyEEh4bE=.fbcc7b72-8298-4702-935e-cc59d60dc219@github.com>
 <IrKH9LoQfUxwjyOgctY0bXsvv9JKLchGYMEwgXR4U9c=.84640b4b-3502-4737-89a5-24d6860ae57a@github.com>
 <MxYi4-yIihxeKsgF0qlseZA03IW5z4hg-aREv5CBCNM=.d8991dc0-25a6-4c0c-90be-00f0346b61b2@github.com>
Message-ID: <SL5xvGHcANoBr2vn7KRNFa8Nk--HmOKIhaLBUBYHux8=.f29fe6c7-ba24-45a4-90b9-c59771a55eb9@github.com>

On Mon, 9 Sep 2024 16:25:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @dholmes-ora Is this really possible? The `obj` ref is passed to the PhantomReference constructor, which stores it in a field, the constructed PhantomReference is returned, and it's then used in a reachabilityFence call below. So `obj` should remain reachable the entire time, right?
>
> (As an aside, I wasn't able to determine what any of the Reference classes do if they're created with a null reference. Possibly a spec bug?)

I also agree with @stuart-marks that the moved to near the ned RF for `ref` is sufficient.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20898#discussion_r1751251574

From jpai at openjdk.org  Tue Sep 10 05:36:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 05:36:36 GMT
Subject: RFR: 8339810: Cleanup the code in sun.tools.jar.Main to properly close
 resources and use ZipFile during extract
Message-ID: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>

Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?

As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.

No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.

-------------

Commit messages:
 - 8339810: Cleanup the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract

Changes: https://git.openjdk.org/jdk/pull/20928/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339810
  Stats: 177 lines in 1 file changed: 32 ins; 53 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/20928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20928/head:pull/20928

PR: https://git.openjdk.org/jdk/pull/20928

From cstein at openjdk.org  Tue Sep 10 05:39:17 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Sep 2024 05:39:17 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v10]
In-Reply-To: <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>
Message-ID: <sc-iMOjzfOGiJEBtQYG2FOTR17IPNwA55xb_drW3dKM=.f36dc70e-9506-4cb8-b048-2981ef64fe60@github.com>

On Tue, 10 Sep 2024 04:36:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 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
>  - cleanup testExtractNoDestDirWithPFlag() test
>  - merge latest from master branch
>  - merge latest from master branch
>  - convert the new test to junit
>  - merge latest from master branch
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/56387a09...129375da

src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 268:

> 266:         CREATE_UPDATE_INDEX("create.update.index"),
> 267:         OTHER("other"),
> 268:         EXTRACT("extract");

Is the order number important in this non-public `enum`? If not, I would expect `OTHER` to remain the last/highest entry.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r1751283531

From jpai at openjdk.org  Tue Sep 10 05:49:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 05:49:07 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v4]
In-Reply-To: <N5Ztdj9jf2GmhTm8Ejpdc5zPvFVCocPEnXXm6FLFYJA=.92279f5b-2567-464e-b374-0b7a4b1f657e@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <Gn8hZZh6sOzHO2mttoFY9einys2nCWrpew9NPH2Ltvs=.60ba4237-9ffd-438e-bab7-ee9653a3731f@github.com>
 <N5Ztdj9jf2GmhTm8Ejpdc5zPvFVCocPEnXXm6FLFYJA=.92279f5b-2567-464e-b374-0b7a4b1f657e@github.com>
Message-ID: <_oGktmgDyMxSetVyuY5eZwOwr6lVDVuJTrk-vNXj0b8=.042f429e-a760-45fe-b5c2-68dc16afa42e@github.com>

On Mon, 9 Sep 2024 23:42:59 GMT, fitzsim <duke at openjdk.org> wrote:

>> fitzsim has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - BootClassPathZipFileTest: Use test.classes directory for test ZIPs
>>  - BootClassPathZipFileTest, BootClassPathZipFileCreator: Move to test/jdk/java/util/zip/ZipFile
>
> I pushed the review suggestions.  There were two GitHub Actions failures on `macos-aarch64`, but they look to be occurrences of this existing bug: https://bugs.openjdk.org/browse/JDK-8247940.

Hello @fitzsim, I plan to take a look at this change and also consult with others familiar with the bootclasspath area as well as jar/zip area. I am just noting this now to let you know that the PR hasn't been neglected and I think it will take a while for this to be reviewed given the nature and area of this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2339673199

From cstein at openjdk.org  Tue Sep 10 06:11:06 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Sep 2024 06:11:06 GMT
Subject: RFR: 8339810: Cleanup the code in sun.tools.jar.Main to properly
 close resources and use ZipFile during extract
In-Reply-To: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
References: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
Message-ID: <tBBdMsmKY_XtJPweJU_1bbYa0UT8BKBlwcrCyph4h5s=.addb64bd-dafd-4b1b-a007-9f0c7dce891b@github.com>

On Tue, 10 Sep 2024 05:31:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?
> 
> As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.
> 
> No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1508:

> 1506:      * Lists contents of JAR file, via ZipFile.
> 1507:      */
> 1508:     void list(String fname, String files[]) throws IOException {

Suggestion:

    void list(String fname, String[] files) throws IOException {


Synchronize with the array syntax change in (new) line 1490.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20928#discussion_r1751312267

From jpai at openjdk.org  Tue Sep 10 06:12:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 06:12:09 GMT
Subject: RFR: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and
 laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits
In-Reply-To: <I6iL4C72C87UUZ2oXUrPJj1WlRxfu20qi2cKQK6SOl4=.b9771e2b-6ecd-4ed0-8fde-b21a8224ab9c@github.com>
References: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
 <LgD8LgcZQYd989fsHzZvIsb7VbfY198_AuLv_8kUiMs=.7a0379c7-f190-454b-95fd-cd9efe62ca00@github.com>
 <I6iL4C72C87UUZ2oXUrPJj1WlRxfu20qi2cKQK6SOl4=.b9771e2b-6ecd-4ed0-8fde-b21a8224ab9c@github.com>
Message-ID: <4Ycu5aucxS39NgJu7ZOfmQ7wNGL-lD_FNESfjYerPKA=.e0039c6c-3603-45c3-9625-52e15b004569@github.com>

On Sat, 7 Sep 2024 05:15:56 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Looks good!
>
> @PaulSandoz Thanks for your reviews, I think this patch is trivial so I will merge it.
> 
> @jaikiran All the `YYYXXXVector.java` files are generated from `X-VectorBits.java.template`, so if I change some of them all the others will get their copyright year updated as well.

Thank you Paul and @merykitty for that detail. 

@merykitty, Paul has approved this and I'm guessing you have run the relevant tests to ensure nothing breaks, in which case you can go ahead and integrate this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20895#issuecomment-2339740822

From jpai at openjdk.org  Tue Sep 10 06:17:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 06:17:39 GMT
Subject: RFR: 8339810: Cleanup the code in sun.tools.jar.Main to properly
 close resources and use ZipFile during extract [v2]
In-Reply-To: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
References: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
Message-ID: <VWPJG0ZHvffuaWJ3MSifhSCX0HIfZVgfMT6YXsL6_9E=.1c634dc3-7208-4c74-bf9a-d35815dff400@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?
> 
> As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.
> 
> No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Christian's review - array declaration style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20928/files
  - new: https://git.openjdk.org/jdk/pull/20928/files/a210cffd..adc68550

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20928&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20928&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20928/head:pull/20928

PR: https://git.openjdk.org/jdk/pull/20928

From jpai at openjdk.org  Tue Sep 10 06:17:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 06:17:39 GMT
Subject: RFR: 8339810: Cleanup the code in sun.tools.jar.Main to properly
 close resources and use ZipFile during extract [v2]
In-Reply-To: <tBBdMsmKY_XtJPweJU_1bbYa0UT8BKBlwcrCyph4h5s=.addb64bd-dafd-4b1b-a007-9f0c7dce891b@github.com>
References: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
 <tBBdMsmKY_XtJPweJU_1bbYa0UT8BKBlwcrCyph4h5s=.addb64bd-dafd-4b1b-a007-9f0c7dce891b@github.com>
Message-ID: <7Yx-Rpq110Fo88zxTob4vALtO0x3sgOOkeLVOfofQ28=.8ae45754-d0a3-4470-89a5-f0a2d434f9e3@github.com>

On Tue, 10 Sep 2024 06:08:45 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Christian's review - array declaration style
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1508:
> 
>> 1506:      * Lists contents of JAR file, via ZipFile.
>> 1507:      */
>> 1508:     void list(String fname, String files[]) throws IOException {
> 
> Suggestion:
> 
>     void list(String fname, String[] files) throws IOException {
> 
> 
> Synchronize with the array syntax change in (new) line 1490.

You are right - I missed this line and a few other similar declarations. I've now updated the PR to address them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20928#discussion_r1751317362

From alanb at openjdk.org  Tue Sep 10 07:26:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Sep 2024 07:26:14 GMT
Subject: Integrated: 8338890: Add monitoring/management interface for the
 virtual thread scheduler
In-Reply-To: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
References: <B7SEEyAhHKnBCH0nzT0iJWdM25KCEv1Yk0EWGKn7-_w=.6945df6b-de50-4b13-9be4-41fec7ab80a1@github.com>
Message-ID: <HjaAqNbGUgI4U710FrWoMiY2XZ9MKccQsX4nFlbm3i0=.f0a4b2df-bba2-4f59-bb39-8446b370769b@github.com>

On Mon, 2 Sep 2024 12:25:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR proposes to add a JDK-specific monitoring and management interface for the virtual thread scheduler. The interface is named VirtualThreadSchedulerMXBean and allows JMX based tooling monitor/manage the scheduler's target parallelism and monitor thread counts.
> 
> The JDK 5/6 era JDK-specific management interfaces are in jdk.management/com.sun.management. The proposal here is to start afresh in the jdk.management package, thus establishing a "new home" for JDK-specific management interfaces going forward.
> 
> jdk.test.lib.thread.VThreadRunner is test infrastructure used by several tests to set or ensure some level of parallelism. This is changed from using deep reflection to using the MXBean to access the target parallelism, which requires changes to the `@modules` tag tests in a number of tests (some tests no longer need to open java.base/java.lang).
> 
> (The changes proposed here have been in the loom repo for some time. A related command for the jcmd tool is also in that repo and will be proposed separately).
> 
> Testing: tier1-4

This pull request has now been integrated.

Changeset: 7e2bcf6d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e2bcf6d0010161dfbc50da4031e65cb5482fb77
Stats:     728 lines in 23 files changed: 675 ins; 17 del; 36 mod

8338890: Add monitoring/management interface for the virtual thread scheduler

Reviewed-by: kevinw

-------------

PR: https://git.openjdk.org/jdk/pull/20816

From djelinski at openjdk.org  Tue Sep 10 08:32:08 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Sep 2024 08:32:08 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v5]
In-Reply-To: <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>
Message-ID: <kCjCpteXdvEwpj1CkWj5iMvdDgSauVj-2cH0uJdtKEU=.27ca6411-de49-46b5-8747-c8cf3bb3cac5@github.com>

On Mon, 9 Sep 2024 19:22:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Replace "transparent" with more explicit verbiage

LGTM.

I think the behavior of `File.exists` with regard to links should also be documented, but feel free to leave it out of this PR.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20878#pullrequestreview-2291745058

From vklang at openjdk.org  Tue Sep 10 08:35:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Sep 2024 08:35:16 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME
Message-ID: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>

This PR applies @AlanBateman's patch from the JBS issue.

-------------

Commit messages:
 - Hardening Thread::beforeSleep to not be able to throw OOME as per Alan Batemans ThreadSleepEvent.patch

Changes: https://git.openjdk.org/jdk/pull/20923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299419
  Stats: 19 lines in 2 files changed: 3 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20923/head:pull/20923

PR: https://git.openjdk.org/jdk/pull/20923

From vklang at openjdk.org  Tue Sep 10 08:35:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Sep 2024 08:35:17 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME
In-Reply-To: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
Message-ID: <WlQnrp_YyxDPLDlIE9eRklAo6PpLfctEJcK6WenL7WA=.577f8d23-5a43-44ee-af39-13e34b5f8d61@github.com>

On Mon, 9 Sep 2024 20:40:22 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR applies @AlanBateman's patch from the JBS issue.

@DougLea @AlanBateman This patch seems to side-step the issues we saw with OOME-on-sleep. Which coincidentally should also harden TestDisposerRace.java so if we get this patch merged we should be able to close that one as a duplicate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2340015335

From djelinski at openjdk.org  Tue Sep 10 08:42:11 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Sep 2024 08:42:11 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
Message-ID: <Qazmu_CpE-FITPTnkB77ZQDuL3i274uLjTRd81RBT7s=.3428961f-0770-4204-b00b-e4287d960d06@github.com>

On Mon, 9 Sep 2024 22:29:23 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Measure time the caller spent waiting. Simplify timeoutLeft computation

LGTM

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 443:

> 441:                 // integer overflow (timeout is an int).
> 442:                 // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed
> 443:                 long pktTimeout = Math.clamp(timeout * (1L << retry), 0, Integer.MAX_VALUE);

we may also need to clamp retry to [0,31]. or even less.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20892#pullrequestreview-2291769012
PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1751524517

From dholmes at openjdk.org  Tue Sep 10 08:48:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 08:48:03 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
Message-ID: <A7XBL7OoOu0veAYBDoIskV_y6n7Y9_Ge3bN6LpMTWqQ=.cca1843a-3f5e-425b-95d3-6485eec27db6@github.com>

On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
> 
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
> 
> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
> 
> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
> 
> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
> 
> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

My understanding is that try/finally is needed to ensure the RF is guaranteed to be seen to be executed at the expected location. Otherwise the RF can in theory be moved around.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20898#issuecomment-2340043873

From dholmes at openjdk.org  Tue Sep 10 08:54:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 08:54:13 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <tJrTayNvkJmgyfzTlMAFYsnzL5P7tC5uwQ4TVcVvuws=.554aac42-7071-4a1a-9148-9097f4fb1fa9@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

This seems trivially fine to me. The JEP isn't really relevant for this C code as we have C99 as a minimum for a while now.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20909#pullrequestreview-2291801397

From alanb at openjdk.org  Tue Sep 10 08:57:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Sep 2024 08:57:05 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME
In-Reply-To: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
Message-ID: <XqKxdum19n_8qqPSGXVlYcxvoKOZ_XMax7Lk4eEbTQk=.574b532d-9b3b-4964-8c97-d3eb29e5e77b@github.com>

On Mon, 9 Sep 2024 20:40:22 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR applies @AlanBateman's patch from the JBS issue.

I hope that someone will take pity on the following tests, sadly they need to be updated as they depend methods observed in the call stack.

test/hotspot/jtreg//vmTestbase/nsk/monitoring/stress/thread/strace001.java
test/hotspot/jtreg//vmTestbase/nsk/monitoring/share/ThreadController.java
test/hotspot/jtreg//vmTestbase/nsk/monitoring/share/thread/SleepingThread.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2340062792

From jwaters at openjdk.org  Tue Sep 10 09:05:10 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Sep 2024 09:05:10 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <tJrTayNvkJmgyfzTlMAFYsnzL5P7tC5uwQ4TVcVvuws=.554aac42-7071-4a1a-9148-9097f4fb1fa9@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
 <tJrTayNvkJmgyfzTlMAFYsnzL5P7tC5uwQ4TVcVvuws=.554aac42-7071-4a1a-9148-9097f4fb1fa9@github.com>
Message-ID: <enFX9tJplsmwQFCwmzjZwD5P6egVg-JnxsxV8GrTJDc=.0564ce50-3ea6-47a6-af41-f3130cbb0065@github.com>

On Tue, 10 Sep 2024 08:51:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems trivially fine to me. The JEP isn't really relevant for this C code as we have C99 as a minimum for a while now.
> 
> Thanks

We actually have C11 as a minimum, C99 for Unix and C89 for Windows was our old standard, but that has since changed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340086782

From dholmes at openjdk.org  Tue Sep 10 09:14:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 09:14:11 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <_3Rjp678JLW7L-IYTVij3Trz4bax7oDxJCM5Kil4oHk=.0e43bcca-0b6c-48b4-80e7-409b1ffe8420@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

Yes I misspoke, I should have said we have required at least C99 for a while now. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340105221

From sgehwolf at openjdk.org  Tue Sep 10 09:18:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Sep 2024 09:18:11 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v9]
In-Reply-To: <df3F3nSt_UChIFIyrVjx8dNqvQ3OvIRwhWXcdb8Fy7g=.1afb4075-06a0-4665-b944-772d5c0d4edf@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
 <df3F3nSt_UChIFIyrVjx8dNqvQ3OvIRwhWXcdb8Fy7g=.1afb4075-06a0-4665-b944-772d5c0d4edf@github.com>
Message-ID: <LHhYKw73BYXavQpwntQLzHPaovwONZw0OYl_TvlC5Q4=.4d4864d3-d8b6-48f3-836c-2d98b13c6e7b@github.com>

On Mon, 9 Sep 2024 17:28:16 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>> Severin Gehwolf 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:
>> 
>>  - Adapt JDK-8339148
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comment of WB::host_cpus()
>>  - Handle non-root + CGv2
>>  - Add nested hierarchy to test framework
>>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>>    
>>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/79b21a7e...30f32d22
>
> I have done some testing on RHELs (build with changes from this PR + other 2 container PRs applied):
> **RHEL-8** (cgroup1/non-root)
> - test was skipped correctly
> 
> **RHEL-9** (cgroup2/non-root)
> - I saw failure of `active_processor_count` check.
> - after investigation, I have found, that `cpu` cgroup controller is not delegated to `user at 1000.service` (and children) on rhel-9 (unlike in e.g. fedora) it only had `memory pids` (btw. available controllers at given "level" are listed in `cgroup.controllers` file in cgroups v2)
> - when I modified `user at .service` to also delegate cpu controller, test passed
> 
> Apart from issue with check for `active_processor_count` on RHEL-9/non-root, it looks good. However I don't know how to easily fix issue with `active_processor_count` check. Maybe check could be skipped for non-root. (Work-around is to modify system configuration.)

@zzambers Thanks for taking a look.

> I have done some testing on RHELs (build with changes from this PR + other 2 container PRs applied): **RHEL-8** (cgroup1/non-root)
> 
>     * test was skipped correctly
> 
> 
> **RHEL-9** (cgroup2/non-root)
> 
>     * I saw failure of `active_processor_count` check.
> 
>     * after investigation, I have found, that `cpu` cgroup controller is not delegated to `user at 1000.service` (and children) on rhel-9 (unlike in e.g. fedora) it only had `memory pids` (btw. available controllers at given "level" are listed in `cgroup.controllers` file in cgroups v2)
> 
>     * when I modified `user at .service` to also delegate cpu controller, test passed

Could it be that the setup you've done to employ delegation is similar to this one?
https://github.com/jerboaa/openjdk-cgroupv2-setup/blob/97690683af17b303276ea473fe44b3dde7ead327/config_cgroupv2.yml#L24-L32
 
> Apart from issue with check for `active_processor_count` on RHEL-9/non-root, it looks good. However I don't know how to easily fix issue with `active_processor_count` check. Maybe check could be skipped for non-root. (Work-around is to modify system configuration.)

Do existing podman container tests pass on that system? It seems fair to assume that that's the baseline config for container tests in general: systemd ones or podman/docker. I know that on cg v2 not all container tests pass out-of-the-box. In particular certain CPU awareness tests. Keeping that basic idea in terms of required config for those tests consistent with other container tests seem adequate to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2340114316

From msheppar at openjdk.org  Tue Sep 10 09:41:05 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 10 Sep 2024 09:41:05 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
Message-ID: <z7cEe7A4qMiaBY94lB-anFGMBYg-ydhuenuQ4ypT2m4=.53900f04-f18d-4418-9779-528e7c06eed1@github.com>

On Mon, 9 Sep 2024 22:29:23 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Measure time the caller spent waiting. Simplify timeoutLeft computation

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 442:

> 440:                 // use 1L below to ensure conversion to long and avoid potential
> 441:                 // integer overflow (timeout is an int).
> 442:                 // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed

if I have read this correctly,  timeout is of type int, thus int Math.clamp(int, int, int) is being called returning type int and promoting to long. Are the any side effects to consider here?  And as timeoutLeft (or remainingTimeout) and pktTimeout were both int and now is type long, then why have timeout declared as type  int ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1751619463

From redestad at openjdk.org  Tue Sep 10 09:49:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 09:49:07 GMT
Subject: RFR: 8339800: Prefer invokeBasic in BootstrapMethodInvokers
In-Reply-To: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>
References: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>
Message-ID: <ccsMjPg0gOKu6V6QODdU2UnyU-nhxAiSmgMcAPak_u4=.c5665102-0779-46c6-ad76-06b8ab5d0b54@github.com>

On Mon, 9 Sep 2024 23:52:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Switching to `invokeBasic` for type-checked invokes in `BootstrapMethodInvokers` instead of `invokeExact` avoids some `MethodHandleNatives.linkMethod` calls during bootstrap. This brings a tiny but measurable once-per-bootstrap method win. Both before and after we lean on the static casts in BootstrapMethodInvokers to sanitize against type mismatches.

Thanks for reviewing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20926#issuecomment-2340182102

From redestad at openjdk.org  Tue Sep 10 09:49:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 09:49:08 GMT
Subject: Integrated: 8339800: Prefer invokeBasic in BootstrapMethodInvokers
In-Reply-To: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>
References: <I487P_dUM79THq4WOqSEqoTJOoAZjjDxZNYmG6QpVx4=.86a3a4f4-62f2-43bd-877f-f4ddde8fcf7a@github.com>
Message-ID: <Vvfty6kXU637h_qbB_ZcpXVB1iN_ZNJ_CT5tXOE1BGs=.1b9c5bb1-c9a9-4285-8393-d91fcc38936f@github.com>

On Mon, 9 Sep 2024 23:52:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Switching to `invokeBasic` for type-checked invokes in `BootstrapMethodInvokers` instead of `invokeExact` avoids some `MethodHandleNatives.linkMethod` calls during bootstrap. This brings a tiny but measurable once-per-bootstrap method win. Both before and after we lean on the static casts in BootstrapMethodInvokers to sanitize against type mismatches.

This pull request has now been integrated.

Changeset: 0d8e52b3
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d8e52b382432674533c9b80565eadf39ae83c64
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8339800: Prefer invokeBasic in BootstrapMethodInvokers

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/20926

From jpai at openjdk.org  Tue Sep 10 09:51:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 09:51:29 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests
Message-ID: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>

Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?

As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.

There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

-------------

Commit messages:
 - 8339834: Replace usages of -mx and -ms in some tests

Changes: https://git.openjdk.org/jdk/pull/20930/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339834
  Stats: 15 lines in 8 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20930/head:pull/20930

PR: https://git.openjdk.org/jdk/pull/20930

From msheppar at openjdk.org  Tue Sep 10 09:52:06 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 10 Sep 2024 09:52:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
Message-ID: <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>

On Mon, 9 Sep 2024 22:29:23 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Measure time the caller spent waiting. Simplify timeoutLeft computation

test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java line 112:

> 110:             // Check that elapsed time is as long as expected, and
> 111:             // not more than 67% greater. Given the min DNS timeout
> 112:             // correction above the threshold value is equal to 61%.

this is a bit arcane, why not have a simple measure that elapsed time shouldn't be more than twice the expected timeout ... this is not that different to the  multipliedBy(2) and multipliedBy(3) --  elaspedTime.compareTo(expectedTime.multipliedBy(2) <= 0

Additionally based on the internal minimum timeout allowance of 50 secs and this upper bound calculation, it would suggest that an @implNote might be useful, or required, to alert developers  to potential timeout variability, and not to rely on timeout to be absolutely (real time) precise

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1751636105

From stuefe at openjdk.org  Tue Sep 10 10:22:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Sep 2024 10:22:10 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <DxVBPLd82bqHdfp-RBH-mb2Sh6BufazXdS6iIP4P0UM=.4d6172d0-5092-49c2-9663-e84a90a5d14c@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

This looks good to me.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2292015058

From redestad at openjdk.org  Tue Sep 10 10:32:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 10:32:05 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v6]
In-Reply-To: <9ls0kBdzdPcFkhX7afFDPyt77Td9vF76d0zhH6qAuSw=.64bc9876-c3a2-43b9-ba2d-3f170f7d6956@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <9ls0kBdzdPcFkhX7afFDPyt77Td9vF76d0zhH6qAuSw=.64bc9876-c3a2-43b9-ba2d-3f170f7d6956@github.com>
Message-ID: <R2ajMscuvK6luanLYQNu7YS21oNjSlEvFiW4t7E2lkc=.d70905b2-d4f3-45dc-9a26-91f9db4abea8@github.com>

On Mon, 9 Sep 2024 17:20:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
>> 
>> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
>> 
>> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more 2 arguments simple concat

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 529:

> 527:                 mh = simpleConcat3(paramType0);
> 528:                 mh = MethodHandles.insertArguments(mh, 0, prefix);
> 529:                 return MethodHandles.filterArguments(mh, 1, objectStringifier());

While this is a fun trick it seems like there's a non-trivial cost here? We'd go down different paths and generate different classes for `"foo" + bar + baz` and `"foo" + bar + " .. " + baz` with this. Special casing when we get the added shapes for more or less free (plain `simpleConcat()`) is a different matter but here you need to construct a new couple of shapes with `insert-` and `filterArguments`.

(Check on paramType1 could be `!paramType1.isPrimitive()`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1751694776

From redestad at openjdk.org  Tue Sep 10 11:02:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 11:02:14 GMT
Subject: RFR: 8339837: Remove unused
 BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM
Message-ID: <5EPiQgfgrzKyrX07uvXuw-VGNbuiP2ZshBdMw6wyc3M=.8b284625-cf35-4f03-9745-8bfb2779c7e0@github.com>

Trivially remove a static optimization mapping for a non-existent method in LambdaMetafactory. The referenced method was refactored into a set of factory methods in java.lang.invoke.ConstantBootstraps before ever becoming a public API.

-------------

Commit messages:
 - Remove unused BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM

Changes: https://git.openjdk.org/jdk/pull/20932/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20932&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339837
  Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20932/head:pull/20932

PR: https://git.openjdk.org/jdk/pull/20932

From jpai at openjdk.org  Tue Sep 10 11:10:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 11:10:38 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
Message-ID: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>

> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
> 
> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update JImageToolTest too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20930/files
  - new: https://git.openjdk.org/jdk/pull/20930/files/51d15461..8214fdb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20930/head:pull/20930

PR: https://git.openjdk.org/jdk/pull/20930

From dholmes at openjdk.org  Tue Sep 10 11:10:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 11:10:38 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
Message-ID: <kft-wWmR2KaY2rgRRBAFQVrSQT1Dl6ggsLupQblUWjM=.1318f1d6-f971-4921-9d4c-6a7acb247663@github.com>

On Tue, 10 Sep 2024 11:07:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageToolTest too

LGTM!

Thanks for cleaning this up.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2292111663

From djelinski at openjdk.org  Tue Sep 10 11:36:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Sep 2024 11:36:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>

On Fri, 9 Aug 2024 17:59:12 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

make/modules/java.base/Lib.gmk line 48:

> 46:     OPTIMIZATION := LOW, \
> 47:     EXTRA_HEADER_DIRS := \
> 48:         libjava/nio/ch, \

This appears to be unneeded

make/modules/java.base/Lib.gmk line 81:

> 79:         libjava/nio/ch \
> 80:         libnio/ch \
> 81:         libnio/fs \

libnio/fs is gone on all platforms other than aix; is this still necessary?

make/modules/java.base/lib/CoreLibraries.gmk line 71:

> 69:         -framework Foundation \
> 70:         -framework SystemConfiguration, \
> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \

Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:

> 573:      * Used to trigger loading of native libraries
> 574:      */
> 575:     public static void load() { }

do we still need this method?

src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.

No changes in this file

src/java.base/unix/native/libnio/ch/NIOUtil.c line 34:

> 32: #include "jvm.h"
> 33: #include "jlong.h"
> 34: #include "sun_nio_ch_IOUtil.h"

should this be NIOUtil?

src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097:

> 1095: 
> 1096:     static {
> 1097:         jdk.internal.loader.BootLoader.loadLibrary("net");

...do we still need net here?

src/java.base/windows/native/libnio/ch/NIOUtil.c line 41:

> 39: 
> 40: JNIEXPORT jboolean JNICALL
> 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed

unused

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751645238
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751648219
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751651925
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751744295
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751746774
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751766398
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751770939
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751774903

From jvernee at openjdk.org  Tue Sep 10 11:44:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Sep 2024 11:44:04 GMT
Subject: RFR: 8339837: Remove unused
 BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM
In-Reply-To: <5EPiQgfgrzKyrX07uvXuw-VGNbuiP2ZshBdMw6wyc3M=.8b284625-cf35-4f03-9745-8bfb2779c7e0@github.com>
References: <5EPiQgfgrzKyrX07uvXuw-VGNbuiP2ZshBdMw6wyc3M=.8b284625-cf35-4f03-9745-8bfb2779c7e0@github.com>
Message-ID: <wJeRjS9n8tb0LKGyOimnIvgnbTEeagpIl--Jg7N9WkQ=.3051f0fc-948b-4ceb-9b69-f3adde10a7ef@github.com>

On Tue, 10 Sep 2024 10:58:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially remove a static optimization mapping for a non-existent method in LambdaMetafactory. The referenced method was refactored into a set of factory methods in java.lang.invoke.ConstantBootstraps before ever becoming a public API.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20932#pullrequestreview-2292184498

From coleenp at openjdk.org  Tue Sep 10 11:48:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Sep 2024 11:48:13 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <d_kD2kEyoltejPurPGNtkZpsrkZV35cyOy_wNORZ_1Q=.300a897e-7d9c-44de-bd3b-f6829a011e03@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2340431106

From coleenp at openjdk.org  Tue Sep 10 11:48:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Sep 2024 11:48:13 GMT
Subject: Integrated: 8338526: Don't store abstract and interface Klasses in
 class metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <vN4gNmjaxrIYArwvCS2ZpWoVStg6LVbJF1bkFun2dJY=.075b1c7b-e9c2-4cef-9ce3-cf382c3b51b6@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

This pull request has now been integrated.

Changeset: ad104932
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a
Stats:     92 lines in 19 files changed: 42 ins; 12 del; 38 mod

8338526: Don't store abstract and interface Klasses in class metaspace

Reviewed-by: stuefe, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/19157

From zzambers at openjdk.org  Tue Sep 10 12:15:16 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 10 Sep 2024 12:15:16 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v9]
In-Reply-To: <df3F3nSt_UChIFIyrVjx8dNqvQ3OvIRwhWXcdb8Fy7g=.1afb4075-06a0-4665-b944-772d5c0d4edf@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
 <df3F3nSt_UChIFIyrVjx8dNqvQ3OvIRwhWXcdb8Fy7g=.1afb4075-06a0-4665-b944-772d5c0d4edf@github.com>
Message-ID: <Lygh0ecvjQAf7JDIgQkefXBp0Qnxbiko3682g_oMQPI=.c8629397-ab96-48bd-b65f-52528388a2ef@github.com>

On Mon, 9 Sep 2024 17:28:16 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>> Severin Gehwolf 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:
>> 
>>  - Adapt JDK-8339148
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comment of WB::host_cpus()
>>  - Handle non-root + CGv2
>>  - Add nested hierarchy to test framework
>>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>>    
>>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/dd1b7120...30f32d22
>
> I have done some testing on RHELs (build with changes from this PR + other 2 container PRs applied):
> **RHEL-8** (cgroup1/non-root)
> - test was skipped correctly
> 
> **RHEL-9** (cgroup2/non-root)
> - I saw failure of `active_processor_count` check.
> - after investigation, I have found, that `cpu` cgroup controller is not delegated to `user at 1000.service` (and children) on rhel-9 (unlike in e.g. fedora) it only had `memory pids` (btw. available controllers at given "level" are listed in `cgroup.controllers` file in cgroups v2)
> - when I modified `user at .service` to also delegate cpu controller, test passed
> 
> Apart from issue with check for `active_processor_count` on RHEL-9/non-root, it looks good. However I don't know how to easily fix issue with `active_processor_count` check. Maybe check could be skipped for non-root. (Work-around is to modify system configuration.)

> @zzambers Thanks for taking a look.
> 
> > I have done some testing on RHELs (build with changes from this PR + other 2 container PRs applied): **RHEL-8** (cgroup1/non-root)
> > ```
> > * test was skipped correctly
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > **RHEL-9** (cgroup2/non-root)
> > ```
> > * I saw failure of `active_processor_count` check.
> > 
> > * after investigation, I have found, that `cpu` cgroup controller is not delegated to `user at 1000.service` (and children) on rhel-9 (unlike in e.g. fedora) it only had `memory pids` (btw. available controllers at given "level" are listed in `cgroup.controllers` file in cgroups v2)
> > 
> > * when I modified `user at .service` to also delegate cpu controller, test passed
> > ```
> 
> Could it be that the setup you've done to employ delegation is similar to this one? https://github.com/jerboaa/openjdk-cgroupv2-setup/blob/97690683af17b303276ea473fe44b3dde7ead327/config_cgroupv2.yml#L24-L32

I have just added `cpu` to Delegate list of `user at .service`, looks similar, to what is done there. I see use of `Delegate=yes` in your link, that probably delegates all.
Thanks for this link. 

> 
> > Apart from issue with check for `active_processor_count` on RHEL-9/non-root, it looks good. However I don't know how to easily fix issue with `active_processor_count` check. Maybe check could be skipped for non-root. (Work-around is to modify system configuration.)
> 
> Do existing podman container tests pass on that system? It seems fair to assume that that's the baseline config for container tests in general: systemd ones or podman/docker. I know that on cg v2 not all container tests pass out-of-the-box. In particular certain CPU awareness tests. Keeping that basic idea in terms of required config for those tests consistent with other container tests seem adequate to me.

You are right. I have ran container tests in my VM and indeed faced issue with missing cpuset controller.
(yesterday I forgot to set required properties, so most of them got skipped)

Interesting that we have not faced this issue in our testing (container tests are passing). However that is probably because we run containers tests in different way (we don't use VMs for it, but rather run them in beaker). I would need to investigate.

Anyway good to know, there can be this issue with cgroup controllers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2340526280

From duke at openjdk.org  Tue Sep 10 12:23:09 2024
From: duke at openjdk.org (duke)
Date: Tue, 10 Sep 2024 12:23:09 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v11]
In-Reply-To: <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
Message-ID: <U3_uxJjTDbtN2IgoFRilW4MwxUTOugq-tsd--8tcsuY=.5830e076-1d42-42e0-8562-80f7ae7d10c4@github.com>

On Mon, 9 Sep 2024 01:53:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @cl4es

@wenshao 
Your change (at version 6c69ab3466a1b914ffb1fc020665be92822111bd) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2340551628

From sgehwolf at openjdk.org  Tue Sep 10 12:29:08 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Sep 2024 12:29:08 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v9]
In-Reply-To: <Lygh0ecvjQAf7JDIgQkefXBp0Qnxbiko3682g_oMQPI=.c8629397-ab96-48bd-b65f-52528388a2ef@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <QBWKrP6mZ-FtCcw_YQapC_SCm-K1e3AEc8id_GwS4x4=.e63e8a66-3ee9-441f-b2e1-64a8468fa081@github.com>
 <df3F3nSt_UChIFIyrVjx8dNqvQ3OvIRwhWXcdb8Fy7g=.1afb4075-06a0-4665-b944-772d5c0d4edf@github.com>
 <Lygh0ecvjQAf7JDIgQkefXBp0Qnxbiko3682g_oMQPI=.c8629397-ab96-48bd-b65f-52528388a2ef@github.com>
Message-ID: <rlbBcqpzbdeoWR29U_OoK6WN29xCJ8rQz_bZcZrwAVk=.b2e43257-cef3-4abb-a0fa-b72b540a93e6@github.com>

On Tue, 10 Sep 2024 12:12:50 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> I have just added `cpu` to Delegate list of `user at .service`, looks similar, to what is done there. I see use of `Delegate=yes` in your link, that probably delegates all.
> Thanks for this link.

FWIW, I was able to reproduce what you said on RHEL 9 when run as user. The mentioned config fixes it. I'll add a hint when the assertion fails.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2340572838

From redestad at openjdk.org  Tue Sep 10 12:35:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 12:35:04 GMT
Subject: RFR: 8339837: Remove unused
 BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM
In-Reply-To: <wJeRjS9n8tb0LKGyOimnIvgnbTEeagpIl--Jg7N9WkQ=.3051f0fc-948b-4ceb-9b69-f3adde10a7ef@github.com>
References: <5EPiQgfgrzKyrX07uvXuw-VGNbuiP2ZshBdMw6wyc3M=.8b284625-cf35-4f03-9745-8bfb2779c7e0@github.com>
 <wJeRjS9n8tb0LKGyOimnIvgnbTEeagpIl--Jg7N9WkQ=.3051f0fc-948b-4ceb-9b69-f3adde10a7ef@github.com>
Message-ID: <yAWuPHkL3XE9J56-VVGWuQe4QSDI91LaRhVS8s0Ggu8=.d899cffa-8a3f-48d9-8a1c-9391260534d3@github.com>

On Tue, 10 Sep 2024 11:41:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Trivially remove a static optimization mapping for a non-existent method in LambdaMetafactory. The referenced method was refactored into a set of factory methods in java.lang.invoke.ConstantBootstraps before ever becoming a public API.
>
> Marked as reviewed by jvernee (Reviewer).

Thanks @JornVernee !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20932#issuecomment-2340595839

From redestad at openjdk.org  Tue Sep 10 12:36:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 12:36:18 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v11]
In-Reply-To: <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <dXOOABpI4rPF1DTFcT0HuY36zUd_RaAaaDaLz7Ci55M=.4027adca-823d-4b53-a590-2a99b35b18d0@github.com>
Message-ID: <M3X12W1oUArXhdzYn5V-RSrnjqFtK-1ug-KD2VQ_oDY=.04923adf-1fdd-4752-a8ce-bdd020fd85fd@github.com>

On Mon, 9 Sep 2024 01:53:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @cl4es

Might take a few weeks for registrar to process the CFV result for your new committer role.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2340593957

From swen at openjdk.org  Tue Sep 10 12:36:19 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 10 Sep 2024 12:36:19 GMT
Subject: Integrated: 8338930: StringConcatFactory hardCoded string
 concatenation strategy
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <76x3H1xSUTtV7M1WBN1X_tqvsoA-NhAZflT-kuUDflo=.788a8f01-8bb4-4c8d-bed4-1a9ad753def8@github.com>

On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

This pull request has now been integrated.

Changeset: 4d597de8
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d597de893dad79e74a280f3f9e82f0a14f9045d
Stats:     132 lines in 3 files changed: 83 ins; 2 del; 47 mod

8338930: StringConcatFactory hardCoded string concatenation strategy

Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20675

From redestad at openjdk.org  Tue Sep 10 12:38:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 12:38:11 GMT
Subject: Integrated: 8339837: Remove unused
 BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM
In-Reply-To: <5EPiQgfgrzKyrX07uvXuw-VGNbuiP2ZshBdMw6wyc3M=.8b284625-cf35-4f03-9745-8bfb2779c7e0@github.com>
References: <5EPiQgfgrzKyrX07uvXuw-VGNbuiP2ZshBdMw6wyc3M=.8b284625-cf35-4f03-9745-8bfb2779c7e0@github.com>
Message-ID: <s2eSXtCBJxIDo5Wr8CmqRK9fuOVhH8UNH90EQ0Diy84=.88baad33-3d71-4d54-ab2b-a856e9df121b@github.com>

On Tue, 10 Sep 2024 10:58:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially remove a static optimization mapping for a non-existent method in LambdaMetafactory. The referenced method was refactored into a set of factory methods in java.lang.invoke.ConstantBootstraps before ever becoming a public API.

This pull request has now been integrated.

Changeset: fb51c1e5
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb51c1e57b9bba876b6b5370c53abbd3196b8b2d
Stats:     16 lines in 1 file changed: 0 ins; 16 del; 0 mod

8339837: Remove unused BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/20932

From syan at openjdk.org  Tue Sep 10 12:45:08 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Sep 2024 12:45:08 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <rri6shNqthGJ3Nb6o8Gdzh4EcTCVEgqqpOj3k3OoQfs=.69b88ba0-de50-4a70-b8f8-5d00875fcd09@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

Thanks all for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340620724

From duke at openjdk.org  Tue Sep 10 12:45:08 2024
From: duke at openjdk.org (duke)
Date: Tue, 10 Sep 2024 12:45:08 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <rth33oTL_eJZrU5ZoCKbt_SQnvGnSt-VJR1cID5A5y4=.e2d15ac8-b59e-48af-b8d9-e474368bbe59@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

@sendaoYan 
Your change (at version bf2ceae0fc34a21760414472805c0bda5ca4a3db) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340629392

From qamai at openjdk.org  Tue Sep 10 12:48:09 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Sep 2024 12:48:09 GMT
Subject: Integrated: 8339677: [vectorapi] YYYXXXVector::withLaneHelper and
 laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits
In-Reply-To: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
References: <9qPof7y8wnoyc30m6rKFnpM_ul-yrsCGZF6Ft-Pfec4=.3f96588f-f749-4e6e-8f2a-2842cd9666a4@github.com>
Message-ID: <jwpm_WJNtKOplURZcqDAUbxvQEjNmR9buzkySPT2QQc=.fa94c065-a51e-4754-b275-8fcb324a97da@github.com>

On Fri, 6 Sep 2024 18:31:00 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes an issue where we mistakenly use `Double::doubleToLongBits` in `DoubleXXXVector::withLaneHelper` and `DoubleXXXVector::laneHelper`. We should use the raw bit version instead.
> 
> Please kindly review, thanks very much.

This pull request has now been integrated.

Changeset: 38441b3f
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38441b3f2d0e735089c29a9a9ce441b2d7c75db1
Stats:     1997 lines in 65 files changed: 373 ins; 1302 del; 322 mod

8339677: [vectorapi] YYYXXXVector::withLaneHelper and laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/20895

From swen at openjdk.org  Tue Sep 10 13:13:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 10 Sep 2024 13:13:22 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v7]
In-Reply-To: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
Message-ID: <hCfPK6RKmGfpFgGwHjbQVBRKYGJ4M-pI97RvEFWXudU=.60bb1de8-e3d3-4808-ac0b-45552b184ce2@github.com>

> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
> 
> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
> 
> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove 2 arguments simple concat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20726/files
  - new: https://git.openjdk.org/jdk/pull/20726/files/ed070af2..de3c1d70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20726&range=05-06

  Stats: 19 lines in 1 file changed: 0 ins; 16 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20726/head:pull/20726

PR: https://git.openjdk.org/jdk/pull/20726

From sgehwolf at openjdk.org  Tue Sep 10 13:23:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Sep 2024 13:23:45 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v10]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <x_r2mKyvSMs8JhSD7Wiu3OyF_tCXa1MaC4Dje5yphco=.1ef712ad-9c61-45a2-b4bf-aec03fef6155@github.com>

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
> - [x] GHA

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Improve reliability of cpu quota test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19530/files
  - new: https://git.openjdk.org/jdk/pull/19530/files/30f32d22..0e52e004

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=08-09

  Stats: 30 lines in 2 files changed: 15 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530

PR: https://git.openjdk.org/jdk/pull/19530

From swen at openjdk.org  Tue Sep 10 13:27:08 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 10 Sep 2024 13:27:08 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v6]
In-Reply-To: <R2ajMscuvK6luanLYQNu7YS21oNjSlEvFiW4t7E2lkc=.d70905b2-d4f3-45dc-9a26-91f9db4abea8@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <9ls0kBdzdPcFkhX7afFDPyt77Td9vF76d0zhH6qAuSw=.64bc9876-c3a2-43b9-ba2d-3f170f7d6956@github.com>
 <R2ajMscuvK6luanLYQNu7YS21oNjSlEvFiW4t7E2lkc=.d70905b2-d4f3-45dc-9a26-91f9db4abea8@github.com>
Message-ID: <ZFEPGIME5kpOe7NolvRTZwzNSMb2Rmp14KJneJ1-m6A=.3a13650d-de35-4392-910f-5cc5d201f441@github.com>

On Tue, 10 Sep 2024 10:28:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more 2 arguments simple concat
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 529:
> 
>> 527:                 mh = simpleConcat3(paramType0);
>> 528:                 mh = MethodHandles.insertArguments(mh, 0, prefix);
>> 529:                 return MethodHandles.filterArguments(mh, 1, objectStringifier());
> 
> While this is a fun trick it seems like there's a non-trivial cost here? We'd go down different paths and generate different classes for `"foo" + bar + baz` and `"foo" + bar + " .. " + baz` with this. Special casing when we get the added shapes for more or less free (plain `simpleConcat()`) is a different matter but here you need to construct a new couple of shapes with `insert-` and `filterArguments`.
> 
> (Check on paramType1 could be `!paramType1.isPrimitive()`)

I'm also not sure how much cost the simpleConcat handling of the 2 parameters would bring, I've removed that, and this is more appropriately implemented by the InlineHiddenClassStrategy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1751961145

From zzambers at openjdk.org  Tue Sep 10 13:28:13 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 10 Sep 2024 13:28:13 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <_PBSCDW3EI69FBqycC9IM-GYWlcgpM7I3qTsEiRJp6g=.fcf693ac-501a-4084-ab40-58d1fe895c0b@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
 <_PBSCDW3EI69FBqycC9IM-GYWlcgpM7I3qTsEiRJp6g=.fcf693ac-501a-4084-ab40-58d1fe895c0b@github.com>
Message-ID: <3xrkC7uUJpfmJrcERIl69CM8G5fbKONia5lCFzsiMK4=.2ea93ff8-1721-4f3c-90b1-70b86f98a03c@github.com>

On Tue, 10 Sep 2024 13:23:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Looking through the coding it looks more or less okay to me; but if you really need to run it under user 'root'  I think we will not have so much use for this in our test environments  because we use other test users.
>> Not saying that this is a very bad thing,  maybe it is just the way it is, that 'root' is needed ?
>
> @MBaesken @zzambers I've updated this patch which should cover the config issue as pointed out by @zzambers. The latest version throws `SkippedException` with a hint should the match fail. Done in https://github.com/openjdk/jdk/pull/19530/commits/0e52e004e9766301294743aa42c8306d7a25a34f and added this info to the bug as well.
> 
> Good to go now?

@jerboaa Looks good, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2340777251

From sgehwolf at openjdk.org  Tue Sep 10 13:28:13 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Sep 2024 13:28:13 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
Message-ID: <_PBSCDW3EI69FBqycC9IM-GYWlcgpM7I3qTsEiRJp6g=.fcf693ac-501a-4084-ab40-58d1fe895c0b@github.com>

On Fri, 30 Aug 2024 11:05:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Add Whitebox check for host cpu
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comments
>>  - 8333446: Add tests for hierarchical container support
>
> Looking through the coding it looks more or less okay to me; but if you really need to run it under user 'root'  I think we will not have so much use for this in our test environments  because we use other test users.
> Not saying that this is a very bad thing,  maybe it is just the way it is, that 'root' is needed ?

@MBaesken @zzambers I've updated this patch which should cover the config issue as pointed out by @zzambers. The latest version throws `SkippedException` with a hint should the match fail. Done in https://github.com/openjdk/jdk/pull/19530/commits/0e52e004e9766301294743aa42c8306d7a25a34f and added this info to the bug as well.

Good to go now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2340771546

From liach at openjdk.org  Tue Sep 10 13:31:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Sep 2024 13:31:10 GMT
Subject: RFR: 8339799: Reduce work done in j.l.invoke bytecode generators
In-Reply-To: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
References: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
Message-ID: <HFH5RBCa4CPOLy7Pii6cDdt5tQJilNTAHWx-5ebzPms=.4361f039-c933-4c36-b364-7e09eb1fc88a@github.com>

On Mon, 9 Sep 2024 22:53:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
> - Define `ClassEntry` early, use it when profitable (there are some warts in the API where using `ce.name(), ce.type()` in a few places means we drop the link to the `ClassDesc` which will then be re-spun in later - should be revisited)
> - Use `mh.invokeBasic()` for zero-arg non-capturing lambda constructor calls(!) 
> - Narrow name validation to the name passed in
> - We were calling `classDesc` twice per factoryType argument, refactored to reuse `argDescs`. 
> 
> Interpreter instrumentation sees 1.5% less bytecode executed on netty startup tests, -2.5% on minimal lambda test. Part of the https://bugs.openjdk.org/browse/JDK-8338542 ClassFile API startup work.

After all, this patch will still be valid with ClassEntry hash updates.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20925#pullrequestreview-2292533283

From zzambers at openjdk.org  Tue Sep 10 13:32:09 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 10 Sep 2024 13:32:09 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v10]
In-Reply-To: <x_r2mKyvSMs8JhSD7Wiu3OyF_tCXa1MaC4Dje5yphco=.1ef712ad-9c61-45a2-b4bf-aec03fef6155@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <x_r2mKyvSMs8JhSD7Wiu3OyF_tCXa1MaC4Dje5yphco=.1ef712ad-9c61-45a2-b4bf-aec03fef6155@github.com>
Message-ID: <iCKDCgjz9ba8WbKgODHHLweTDLG9T5KPOazTcWqmCT0=.16012a3e-52eb-46da-ad05-f36863396ff1@github.com>

On Tue, 10 Sep 2024 13:23:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
>> - [x] GHA
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve reliability of cpu quota test

Marked as reviewed by zzambers (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19530#pullrequestreview-2292534579

From ihse at openjdk.org  Tue Sep 10 13:33:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Sep 2024 13:33:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>

On Tue, 10 Sep 2024 09:56:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> make/modules/java.base/Lib.gmk line 81:
> 
>> 79:         libjava/nio/ch \
>> 80:         libnio/ch \
>> 81:         libnio/fs \
> 
> libnio/fs is gone on all platforms other than aix; is this still necessary?

We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I <dir>` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course.

> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
> 
> Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms.

I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751967809
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751975461

From redestad at openjdk.org  Tue Sep 10 13:36:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 13:36:08 GMT
Subject: RFR: 8339799: Reduce work done in j.l.invoke bytecode generators
In-Reply-To: <HFH5RBCa4CPOLy7Pii6cDdt5tQJilNTAHWx-5ebzPms=.4361f039-c933-4c36-b364-7e09eb1fc88a@github.com>
References: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
 <HFH5RBCa4CPOLy7Pii6cDdt5tQJilNTAHWx-5ebzPms=.4361f039-c933-4c36-b364-7e09eb1fc88a@github.com>
Message-ID: <poofG9yM5h5o0a3gNE-jQ86qicYtKsNYoPAtv8fvDc4=.155ee334-5054-4527-9a1f-24836b1a039c@github.com>

On Tue, 10 Sep 2024 13:28:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> After all, this patch will still be valid with ClassEntry hash updates.

Thanks for checking and reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20925#issuecomment-2340800697

From redestad at openjdk.org  Tue Sep 10 13:36:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 13:36:09 GMT
Subject: Integrated: 8339799: Reduce work done in j.l.invoke bytecode
 generators
In-Reply-To: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
References: <S8IVbzPZGHfQSJB5MMASbQUEq6vfVXCJHZBKDERkRxs=.7b3915a9-227a-497a-a345-1334df02bc93@github.com>
Message-ID: <0h_7Z8nX70UqP1l71E7vzncZuJVQAl8cW8X0g25ldME=.f4a5d4e9-2179-4620-8682-5e17d07cc516@github.com>

On Mon, 9 Sep 2024 22:53:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
> - Define `ClassEntry` early, use it when profitable (there are some warts in the API where using `ce.name(), ce.type()` in a few places means we drop the link to the `ClassDesc` which will then be re-spun in later - should be revisited)
> - Use `mh.invokeBasic()` for zero-arg non-capturing lambda constructor calls(!) 
> - Narrow name validation to the name passed in
> - We were calling `classDesc` twice per factoryType argument, refactored to reuse `argDescs`. 
> 
> Interpreter instrumentation sees 1.5% less bytecode executed on netty startup tests, -2.5% on minimal lambda test. Part of the https://bugs.openjdk.org/browse/JDK-8338542 ClassFile API startup work.

This pull request has now been integrated.

Changeset: c246ede1
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c246ede163d675cfdacf741565195751981afb41
Stats:     26 lines in 2 files changed: 5 ins; 1 del; 20 mod

8339799: Reduce work done in j.l.invoke bytecode generators

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20925

From chen.l.liang at oracle.com  Tue Sep 10 13:47:54 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 10 Sep 2024 13:47:54 +0000
Subject: Where to ask about a potential bug/oversight with hidden classes
In-Reply-To: <CADxF0cAC9p-73xfuxC=o6ngWYOrheDBQ+mLQsxKHTRgdKwyzPw@mail.gmail.com>
References: <CADxF0cAC9p-73xfuxC=o6ngWYOrheDBQ+mLQsxKHTRgdKwyzPw@mail.gmail.com>
Message-ID: <SJ2PR10MB76694E4E2EEC44E23593D257A29A2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Matias,
Since MethodHandles is a library API, I think we can discuss about this on core-libs list.

About the self-reference replacement: as the spec says, it only happens to the thisClass Class entry in the hidden class. That means if the class is referenced in a method (such as a method's parameter in your class) or field (such as a field's type in your class) descriptor, all of which do not go through Class entries, the reference is kept as-is. So the lack of substitution for NameAndType is working as intended.

Currently, LambdaMetafactory only has limited support for static methods in hidden classes, which was actually not available in release 22 and only added in release 23 development as there's a need from project Babylon. This is not part of LMF's specification and we might adjust this behavior at any time.

For your purpose, you might have to bytecode process the class and patch references manually, or look into using non-hidden classes in custom class loaders instead.

Regards,
Chen
________________________________
From: discuss <discuss-retn at openjdk.org> on behalf of Matias Koivikko <matias.koivikko at gmail.com>
Sent: Tuesday, September 10, 2024 7:35 AM
To: discuss at openjdk.org <discuss at openjdk.org>
Subject: Where to ask about a potential bug/oversight with hidden classes

Hi everyone,

I've been working on a project where I compile custom code to class files and load them using MethodHandles.Lookup#defineHiddenClass into the jvm. This seems like the correct method to me as my classes don't need to be referenced from the outside beyond reflectively calling a single method and they should ideally unload soon after unless they stored references somewhere.

As for the bug, it involves lambdas that capture this and a ClassNotFoundException being thrown for the hidden class. As far as I understand it, the hidden class gets a randomized name at runtime and all references to itself within the class file should be replaced. It seems like this process doesn't work properly for the main NameAndType of an invokedynamic instruction. This would then cause a runtime crash whenever capturing lambdas among other uses of indy are used.

Does anyone have any ideas on what I could have done wrong or where I should take this question further? I assume there's some more appropriate mailing list to discuss this issue in.

Regards, Matias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240910/6ba5f8f8/attachment-0001.htm>

From jeisl at openjdk.org  Tue Sep 10 13:54:23 2024
From: jeisl at openjdk.org (Josef Eisl)
Date: Tue, 10 Sep 2024 13:54:23 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 135:

> 133: #endif
> 134: 
> 135:     if (!JVM_IsStaticallyLinked()) {

These "cross-library" link-type probes are a challenge for GraalVM native image. In native image, we statically link most standard JNI libraries into the final executable. However in some cases, for example AWT, static linking is not feasible due to their dependencies. Thus, we resort to dynamic linking. Have a mix of static and dynamic linking means that `JVM_IsStaticallyLinked` should give different answers based on the caller. Example:
lets assume a follow-up change introduces a call to `JVM_IsStaticallyLinked` in libnet (which native image statically links):
* if `JVM_IsStaticallyLinked` is called from libawt.so, we want to answer `false`
* if `JVM_IsStaticallyLinked` is called from libnet.a, we want to answer `true`

Is the mixed linking use case is something that the Hermetic Java effort is having on its radar?

For this particular case, one solutions could be to avoid cross-library calls. I.e., instead of calling `JVM_IsStaticallyLinked`, have an `AWT_IsStaticallyLinked` that is local to the libawt. This is similar to the pattern also used for JLI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1752023584

From sgehwolf at openjdk.org  Tue Sep 10 14:16:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Sep 2024 14:16:11 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v6]
In-Reply-To: <zcnAOfImTlUcaw_Pc2eCr6_5zJvRp4HfNiZ5wHx6B8s=.54bcf23f-f79c-4ded-b692-4589f416b061@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <zcnAOfImTlUcaw_Pc2eCr6_5zJvRp4HfNiZ5wHx6B8s=.54bcf23f-f79c-4ded-b692-4589f416b061@github.com>
Message-ID: <AMYvDQLTB-W4US654u_EcHMlK1Po0-YmXdUEXm58M3o=.330a8e1a-4cb6-4ae3-aae9-12c32a59ac6f@github.com>

On Thu, 5 Sep 2024 13:25:17 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 proposed 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Add JVM_HostActiveProcessorCount using JVM api
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Adjust test and fix code to return lowest hierarchical limit
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Add root check for SystemdMemoryAwarenessTest
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - 8336881: [Linux] Support for hierarchical limits for Metrics

Thanks. I forgot to update said tests after the latest update. Fixing it now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2340949763

From dfuchs at openjdk.org  Tue Sep 10 14:47:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Sep 2024 14:47:10 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <z7cEe7A4qMiaBY94lB-anFGMBYg-ydhuenuQ4ypT2m4=.53900f04-f18d-4418-9779-528e7c06eed1@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <z7cEe7A4qMiaBY94lB-anFGMBYg-ydhuenuQ4ypT2m4=.53900f04-f18d-4418-9779-528e7c06eed1@github.com>
Message-ID: <hZP4uzXUMxql-RP__r7jE45aRntAw10zratQriiytCs=.73f93478-477b-4b95-b618-b10049b0aaec@github.com>

On Tue, 10 Sep 2024 09:38:35 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Measure time the caller spent waiting. Simplify timeoutLeft computation
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 442:
> 
>> 440:                 // use 1L below to ensure conversion to long and avoid potential
>> 441:                 // integer overflow (timeout is an int).
>> 442:                 // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed
> 
> if I have read this correctly,  timeout is of type int, thus int Math.clamp(int, int, int) is being called returning type int and promoting to long. Are there any side effects to consider here?  And as timeoutLeft (or remainingTimeout) and pktTimeout were both int and now is type long, then why have timeout declared as type  int ? 
> 
> consistency in various declared "timeout" variables' type ?

If I'm not mistaken here  it's `Math.clamp(long, long, long)` which is called - because `timeout * (1L << retry)` is a long. We could make it more obvious by using `0L` instead of `0` too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752129677

From dfuchs at openjdk.org  Tue Sep 10 14:50:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Sep 2024 14:50:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <Qazmu_CpE-FITPTnkB77ZQDuL3i274uLjTRd81RBT7s=.3428961f-0770-4204-b00b-e4287d960d06@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <Qazmu_CpE-FITPTnkB77ZQDuL3i274uLjTRd81RBT7s=.3428961f-0770-4204-b00b-e4287d960d06@github.com>
Message-ID: <GvMTnicqSAJiX2j_t-yrLCWg0QSJw6kxwcEFpdnyblo=.17e1e850-487e-4698-858e-29ffd587abbc@github.com>

On Tue, 10 Sep 2024 08:39:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Measure time the caller spent waiting. Simplify timeoutLeft computation
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 443:
> 
>> 441:                 // integer overflow (timeout is an int).
>> 442:                 // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed
>> 443:                 long pktTimeout = Math.clamp(timeout * (1L << retry), 0, Integer.MAX_VALUE);
> 
> we may also need to clamp retry to [0,31]. or even less.

Agreed - though I don't think it matter much. If the shift overflows to negative `pktTimeout` would become 0 which would be interpreted as wait forever.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752134498

From dfuchs at openjdk.org  Tue Sep 10 14:59:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Sep 2024 14:59:05 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
Message-ID: <QpvA-2frXU-cIjMB_LbGgjNWPYAZ8A6N8bcX2UP9y08=.2901e031-128b-4f38-a1c7-0763292bad80@github.com>

On Mon, 9 Sep 2024 22:29:23 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Measure time the caller spent waiting. Simplify timeoutLeft computation

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 479:

> 477:                     long elapsedMillis = TimeUnit.NANOSECONDS
> 478:                                                  .toMillis(System.nanoTime() - start);
> 479:                     timeoutLeft = pktTimeout - Math.clamp(elapsedMillis, 0, Integer.MAX_VALUE);

Suggestion:

                    timeoutLeft = pktTimeout - elapsedMillis;

Now that timeoutLeft is a long we have no reason to clamp at Integer.MAX_VALUE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752147242

From dfuchs at openjdk.org  Tue Sep 10 15:02:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Sep 2024 15:02:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
Message-ID: <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>

On Tue, 10 Sep 2024 09:49:08 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Measure time the caller spent waiting. Simplify timeoutLeft computation
>
> test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java line 112:
> 
>> 110:             // Check that elapsed time is as long as expected, and
>> 111:             // not more than 67% greater. Given the min DNS timeout
>> 112:             // correction above the threshold value is equal to 61%.
> 
> this is a bit arcane, why not have a simple measure that elapsed time shouldn't be more than twice the expected timeout ... this is not that different to the  multipliedBy(2) and multipliedBy(3) --  elaspedTime.compareTo(expectedTime.multipliedBy(2) <= 0
> 
> Additionally based on the internal minimum timeout allowance of 50 secs and this upper bound calculation, it would suggest that an @implNote might be useful, or required, to alert developers  to potential timeout variability, and not to rely on timeout to be absolutely (real time) precise

I don't think we want to go down the rabbit hole of documenting too much. Agreed that using a simple factor 2 would make the code simpler, but do we want to go that high?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752155232

From djelinski at openjdk.org  Tue Sep 10 15:18:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Sep 2024 15:18:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
Message-ID: <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>

On Tue, 10 Sep 2024 13:30:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
>> 
>> Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms.
>
> I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113).

well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752181579

From sgehwolf at openjdk.org  Tue Sep 10 16:10:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Sep 2024 16:10:21 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v7]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <cU68Aj_Pcz-gG0qXgid15gYXZVYMhkIyNt9JCbmVi34=.bc7e9e0f-0d92-41c8-aecc-d10263a2dbfd@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 proposed 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 incrementally with two additional commits since the last revision:

 - Improve systemd slice test for non-root on cg v2
 - Fix unit tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20280/files
  - new: https://git.openjdk.org/jdk/pull/20280/files/5b210068..b60cd0c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=05-06

  Stats: 96 lines in 3 files changed: 74 ins; 0 del; 22 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 nbenalla at openjdk.org  Tue Sep 10 16:29:31 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 10 Sep 2024 16:29:31 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v12]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <y14-ONQBu-qVygQSs4UgQtlm8eiCCZgsfWG_a0nyLzY=.d614b574-d390-45b7-ba19-495a0cde1930@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - extend SinceChecker to now skip some packages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Skip over files and packages that aren't found
 - Move the tests to module/module_name directory for clearer naming
 - (C)
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
   
   # Conflicts:
   #	test/jdk/TEST.groups
 - Improve checker report messages
 - Merge branch 'master' into source-based-since-checker
 - ... and 15 more: https://git.openjdk.org/jdk/compare/56387a09...90805b21

-------------

Changes: https://git.openjdk.org/jdk/pull/18934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=11
  Stats: 968 lines in 3 files changed: 966 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From duke at openjdk.org  Tue Sep 10 16:42:15 2024
From: duke at openjdk.org (sbgoog)
Date: Tue, 10 Sep 2024 16:42:15 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
Message-ID: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>

FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

-------------

Commit messages:
 - 8339850: Restore the interrupt status in FileSystemPreferences.lockFile()

Changes: https://git.openjdk.org/jdk/pull/20938/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20938&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339850
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20938.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20938/head:pull/20938

PR: https://git.openjdk.org/jdk/pull/20938

From nbenalla at openjdk.org  Tue Sep 10 16:45:23 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 10 Sep 2024 16:45:23 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v13]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <svM3lBk21WqBgtIqylVJ2YXCl_sgXTecOVfc3OUZrWQ=.34af5c39-21a0-4afb-819b-61dcf2988028@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  avoid using `continue`, fix mistake in last commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/90805b21..542f361f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From nbenalla at openjdk.org  Tue Sep 10 16:48:08 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 10 Sep 2024 16:48:08 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v13]
In-Reply-To: <svM3lBk21WqBgtIqylVJ2YXCl_sgXTecOVfc3OUZrWQ=.34af5c39-21a0-4afb-819b-61dcf2988028@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <svM3lBk21WqBgtIqylVJ2YXCl_sgXTecOVfc3OUZrWQ=.34af5c39-21a0-4afb-819b-61dcf2988028@github.com>
Message-ID: <gjuJWh9q2gXSdBmuZZURnPgWkF2pBfPi1JezFdI_9FQ=.e4ec9dd6-9732-483a-8808-ca9827a4e2dc@github.com>

On Tue, 10 Sep 2024 16:45:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid using `continue`, fix mistake in last commit

Currently running tier1,  I added the option to exclude certain packages in an attempt to integrate this faster while we fix other areas.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2341463981

From alanb at openjdk.org  Tue Sep 10 17:36:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Sep 2024 17:36:06 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v5]
In-Reply-To: <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>
Message-ID: <udRAyNdwVIw4bcwwrvRGb96qC3wVg9e3rqd4fOPzfNY=.e7d1475c-56af-418e-936e-25326d846ca7@github.com>

On Mon, 9 Sep 2024 19:22:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Replace "transparent" with more explicit verbiage

src/java.base/share/classes/java/io/File.java line 1440:

> 1438:      * Renames the file denoted by this abstract pathname.  If this pathname
> 1439:      * denotes a symbolic link, then the link itself, not its target, will be
> 1440:      * renamed.

For FIS/FOS/RAF it's just two constructors in each that follow links so I'm wondering if might be better to put the text there. Also in the case of FOS (and RAF when "w" is in the mode) it will follow the linking when creating (or truncating in the case of FOS) the file and part of wonders if we need to say more on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1752389812

From alanb at openjdk.org  Tue Sep 10 17:40:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Sep 2024 17:40:06 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v3]
In-Reply-To: <AdHWmMpeoEX2Unu8lDHj_bvR_5Gsuj_qA-cL8gIP65I=.114a8101-cd97-4473-b3ce-bb27a4c21c8c@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <AdHWmMpeoEX2Unu8lDHj_bvR_5Gsuj_qA-cL8gIP65I=.114a8101-cd97-4473-b3ce-bb27a4c21c8c@github.com>
Message-ID: <yZgsELqGCVoLDtZi7hZN6E1dlyJ9hAqzYWpyMi5Ebgc=.d84920b6-2e39-419a-990b-a7f07abd8d96@github.com>

On Mon, 9 Sep 2024 21:11:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
>> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
>> 
>> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
>> 
>> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add copyright

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20914#pullrequestreview-2293235930

From alanb at openjdk.org  Tue Sep 10 17:51:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Sep 2024 17:51:30 GMT
Subject: RFR: 8338747: hasIncubatorModules needs to be generated when module
 resolution required at startup
Message-ID: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>

This PR proposes changes to the ModuleBootstrap code that is used with CDS (Ahead-of-Time Class Loading & Linking in the future). At things stand, the module graph and boot layer can be archived at dump time (-Xshare:dump) when the initial module is the class path or the initial module is in the run-time image. Future work will extend this to deployments with an application module path or where additional root modules are specified with --add-modules. To get there we need the code that determines whether to archive is in one place, and it needs to know if the module graph contains incubator modules or split packages. 

Testing: tier1-tier6. There are no new tests, the changes don't expand or change what can be archived. Calvin has done some some testing with the change as it is needed for [JDK-8328313](https://bugs.openjdk.org/browse/JDK-8328313).

-------------

Commit messages:
 - Merge
 - Merge
 - Cleanup
 - Merge
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20818/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20818&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338747
  Stats: 72 lines in 1 file changed: 31 ins; 21 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20818.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20818/head:pull/20818

PR: https://git.openjdk.org/jdk/pull/20818

From msheppar at openjdk.org  Tue Sep 10 17:54:07 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 10 Sep 2024 17:54:07 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
Message-ID: <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>

On Tue, 10 Sep 2024 14:59:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java line 112:
>> 
>>> 110:             // Check that elapsed time is as long as expected, and
>>> 111:             // not more than 67% greater. Given the min DNS timeout
>>> 112:             // correction above the threshold value is equal to 61%.
>> 
>> this is a bit arcane, why not have a simple measure that elapsed time shouldn't be more than twice the expected timeout ... this is not that different to the  multipliedBy(2) and multipliedBy(3) --  elaspedTime.compareTo(expectedTime.multipliedBy(2) <= 0
>> 
>> Additionally based on the internal minimum timeout allowance of 50 secs and this upper bound calculation, it would suggest that an @implNote might be useful, or required, to alert developers  to potential timeout variability, and not to rely on timeout to be absolutely (real time) precise
>
> I don't think we want to go down the rabbit hole of documenting too much. Agreed that using a simple factor 2 would make the code simpler, but do we want to go that high?

I don't think it is a rabbit hole, to provide some additional clarity on the timeout mechanism and to avoid any perception that it is an absolute realtime timeout semantics, such that developers have precise view of how the mechanism works

https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752422523

From msheppar at openjdk.org  Tue Sep 10 17:57:06 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 10 Sep 2024 17:57:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <hZP4uzXUMxql-RP__r7jE45aRntAw10zratQriiytCs=.73f93478-477b-4b95-b618-b10049b0aaec@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <z7cEe7A4qMiaBY94lB-anFGMBYg-ydhuenuQ4ypT2m4=.53900f04-f18d-4418-9779-528e7c06eed1@github.com>
 <hZP4uzXUMxql-RP__r7jE45aRntAw10zratQriiytCs=.73f93478-477b-4b95-b618-b10049b0aaec@github.com>
Message-ID: <weZ-A0sazxw2wPCxvQK25QZw9GhfMg2fIKqbz30Mz80=.7ca5e685-0e21-4cdb-ae71-60df362786ae@github.com>

On Tue, 10 Sep 2024 14:44:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 442:
>> 
>>> 440:                 // use 1L below to ensure conversion to long and avoid potential
>>> 441:                 // integer overflow (timeout is an int).
>>> 442:                 // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed
>> 
>> if I have read this correctly,  timeout is of type int, thus int Math.clamp(int, int, int) is being called returning type int and promoting to long. Are there any side effects to consider here?  And as timeoutLeft (or remainingTimeout) and pktTimeout were both int and now is type long, then why have timeout declared as type  int ? 
>> 
>> consistency in various declared "timeout" variables' type ?
>
> If I'm not mistaken here  it's `Math.clamp(long, long, long)` which is called - because `timeout * (1L << retry)` is a long. We could make it more obvious by using `0L` instead of `0` too.

thanks for the clarification ... yes indeed, I didn't see the 1L as the original was (timeout * (1 << retry))
BUT I should have read the comment more precisely(small screens and no glasses !!)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752428852

From bpb at openjdk.org  Tue Sep 10 18:08:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Sep 2024 18:08:06 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v5]
In-Reply-To: <udRAyNdwVIw4bcwwrvRGb96qC3wVg9e3rqd4fOPzfNY=.e7d1475c-56af-418e-936e-25326d846ca7@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>
 <udRAyNdwVIw4bcwwrvRGb96qC3wVg9e3rqd4fOPzfNY=.e7d1475c-56af-418e-936e-25326d846ca7@github.com>
Message-ID: <0IeuGaaPy8TJq6fBQ4TTsOvEDXLcdp4zcxqt9k48Q-g=.a4071de3-bcd9-4677-a9c1-2b963fe63cbf@github.com>

On Tue, 10 Sep 2024 17:33:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> or truncating in the case of FOS

For that matter, I don't see where truncation is explicitly mentioned in the FOS doc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1752446236

From prappo at openjdk.org  Tue Sep 10 18:16:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Sep 2024 18:16:05 GMT
Subject: RFR: 8339789: Use index and definition tags in AnnotatedElement
In-Reply-To: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
References: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
Message-ID: <urP-UZR4qowgLr8uobFs1NKmy1kOc0w41TaehYnwuX4=.7e315f39-079c-4670-ae31-6d4aac7d0e8a@github.com>

On Mon, 9 Sep 2024 18:37:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use index and definition tags in AnnotatedElement.

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20919#pullrequestreview-2293347006

From msheppar at openjdk.org  Tue Sep 10 18:18:04 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 10 Sep 2024 18:18:04 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
 <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
Message-ID: <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>

On Tue, 10 Sep 2024 17:50:59 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> I don't think we want to go down the rabbit hole of documenting too much. Agreed that using a simple factor 2 would make the code simpler, but do we want to go that high?
>
> I don't think it is a rabbit hole, to provide some additional clarity on the timeout mechanism and to avoid any perception that it has absolute realtime timeout semantics, such that developers have precise view of how the mechanism works
> 
> https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html

I think 2 times is good, remove all potential noise  ;-)

the following failures is nearly twice the expected

----------System.out:(3/73)----------
Skip local DNS Server creation
Elapsed (ms): 14229
Expected (ms): 7750
----------System.err:(13/652)----------
java.lang.RuntimeException: Failed: timeout in 14229 ms, expected 7750ms
at Timeout.handleException(Timeout.java:116)
at TestBase.launch(TestBase.java:84)
at TestBase.run(TestBase.java:50)
at Timeout.main(Timeout.java:59)

and  I think it fails  the new upper bound check 

most of the elapsed times that have been less than the expected have been within the 50 * 5  tolerance, but there have been a few outside the -250 mess lower bound

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752480088

From cushon at openjdk.org  Tue Sep 10 18:19:10 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 10 Sep 2024 18:19:10 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v7]
In-Reply-To: <If4E-nt-VM_sg_7yTZnKfPD1wiKZaeVxYeONnR1AzPk=.34a8be90-522a-4d70-bbf1-44295e247a0d@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>
Message-ID: <7LIMvwOnv3J1CcL_gOFvg-WOmWVQLoIt3f8QZTurSSc=.422ead65-89b6-4af1-872c-19b48b73e3ab@github.com>

On Tue, 9 Jul 2024 23:17:47 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 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>

keep-alive, I still want to see if we can evaluate the impact enough to find a path forward for this

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2341694358

From aefimov at openjdk.org  Tue Sep 10 18:41:41 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Sep 2024 18:41:41 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v6]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <J7xHiuKN0VuuPDsHOgzH-z-rHf0dm3wGareMmqVDbvo=.72be079d-b838-4286-b44e-f3baa5bff34f@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with three additional commits since the last revision:

 - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
 - remove redundant clamp from timeoutLeft calculation
 - clamp timeout and retries property values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/4d33d05b..05ed9e05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=04-05

  Stats: 43 lines in 4 files changed: 15 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From aefimov at openjdk.org  Tue Sep 10 18:41:41 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Sep 2024 18:41:41 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <weZ-A0sazxw2wPCxvQK25QZw9GhfMg2fIKqbz30Mz80=.7ca5e685-0e21-4cdb-ae71-60df362786ae@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <z7cEe7A4qMiaBY94lB-anFGMBYg-ydhuenuQ4ypT2m4=.53900f04-f18d-4418-9779-528e7c06eed1@github.com>
 <hZP4uzXUMxql-RP__r7jE45aRntAw10zratQriiytCs=.73f93478-477b-4b95-b618-b10049b0aaec@github.com>
 <weZ-A0sazxw2wPCxvQK25QZw9GhfMg2fIKqbz30Mz80=.7ca5e685-0e21-4cdb-ae71-60df362786ae@github.com>
Message-ID: <bxGQfomjTfmcjwOdQW8NHUQbALrOa7peOFx20xhKCQE=.c70ca263-5578-4cfe-879a-61465fc26c37@github.com>

On Tue, 10 Sep 2024 17:54:30 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> If I'm not mistaken here  it's `Math.clamp(long, long, long)` which is called - because `timeout * (1L << retry)` is a long. We could make it more obvious by using `0L` instead of `0` too.
>
> thanks for the clarification ... yes indeed, I didn't see the 1L as the original was (timeout * (1 << retry))
> BUT I should have read the comment more precisely(small screens and no glasses !!)

Changed `0` -> `0L` to make it more obvious

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752523532

From aefimov at openjdk.org  Tue Sep 10 18:41:42 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Sep 2024 18:41:42 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <QpvA-2frXU-cIjMB_LbGgjNWPYAZ8A6N8bcX2UP9y08=.2901e031-128b-4f38-a1c7-0763292bad80@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <QpvA-2frXU-cIjMB_LbGgjNWPYAZ8A6N8bcX2UP9y08=.2901e031-128b-4f38-a1c7-0763292bad80@github.com>
Message-ID: <__u70EVsivrSZR0DN57iG5iW5jdixZ55E1Uydq-PCRQ=.e23f0797-3016-4b84-9fa7-c26f4712acb4@github.com>

On Tue, 10 Sep 2024 14:54:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Measure time the caller spent waiting. Simplify timeoutLeft computation
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 479:
> 
>> 477:                     long elapsedMillis = TimeUnit.NANOSECONDS
>> 478:                                                  .toMillis(System.nanoTime() - start);
>> 479:                     timeoutLeft = pktTimeout - Math.clamp(elapsedMillis, 0, Integer.MAX_VALUE);
> 
> Suggestion:
> 
>                     timeoutLeft = pktTimeout - elapsedMillis;
> 
> Now that timeoutLeft is a long we have no reason to clamp at Integer.MAX_VALUE.

Thanks fixed in [3abb782](https://github.com/openjdk/jdk/pull/20892/commits/3abb782904cf80d2ed5da70266cdfeea05b1bd2f)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752523889

From aefimov at openjdk.org  Tue Sep 10 18:41:42 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Sep 2024 18:41:42 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
 <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
 <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>
Message-ID: <8gQI8QaHUU8Je6KG15-k-7IwYOw1GNQCZxkJ5UDTMVI=.ba34290b-92eb-4d60-af03-0d8c804c04e4@github.com>

On Tue, 10 Sep 2024 18:15:34 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> I don't think it is a rabbit hole, to provide some additional clarity on the timeout mechanism and to avoid any perception that it has absolute realtime timeout semantics, such that developers have precise view of how the mechanism works
>> 
>> https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html
>
> I think 2 times is good, remove all potential noise  ;-)
> 
> the following failures is nearly twice the expected
> 
> ----------System.out:(3/73)----------
> Skip local DNS Server creation
> Elapsed (ms): 14229
> Expected (ms): 7750
> ----------System.err:(13/652)----------
> java.lang.RuntimeException: Failed: timeout in 14229 ms, expected 7750ms
> at Timeout.handleException(Timeout.java:116)
> at TestBase.launch(TestBase.java:84)
> at TestBase.run(TestBase.java:50)
> at Timeout.main(Timeout.java:59)
> 
> and  I think it fails  the new upper bound check 
> 
> most of the elapsed times that have been less than the expected have been within the 50 * 5  tolerance, but there have been a few outside the -250 mess lower bound

I agree that we don't want to document too much here. Updated the factor to 1.75 (2 seems a bit high and might hide real issues), and to make the timeout value calculation and check less arcane - I have updated test output to print the range of acceptable timeout values: 05ed9e053865293a1938ed7bc6fe208759513813

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752523264

From aefimov at openjdk.org  Tue Sep 10 18:54:06 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Sep 2024 18:54:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <GvMTnicqSAJiX2j_t-yrLCWg0QSJw6kxwcEFpdnyblo=.17e1e850-487e-4698-858e-29ffd587abbc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <Qazmu_CpE-FITPTnkB77ZQDuL3i274uLjTRd81RBT7s=.3428961f-0770-4204-b00b-e4287d960d06@github.com>
 <GvMTnicqSAJiX2j_t-yrLCWg0QSJw6kxwcEFpdnyblo=.17e1e850-487e-4698-858e-29ffd587abbc@github.com>
Message-ID: <ilYHn_HD4sqgTrkX_LDohBeRlL_UlxBIxC6Z9o60ZaA=.f0de2f46-15c6-41ab-83bb-b25ec15701f9@github.com>

On Tue, 10 Sep 2024 14:47:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 443:
>> 
>>> 441:                 // integer overflow (timeout is an int).
>>> 442:                 // no point in supporting timeout > Integer.MAX_VALUE, clamp if needed
>>> 443:                 long pktTimeout = Math.clamp(timeout * (1L << retry), 0, Integer.MAX_VALUE);
>> 
>> we may also need to clamp retry to [0,31]. or even less.
>
> Agreed - though I don't think it matter much. If the shift overflows to negative `pktTimeout` would become 0 which would be interpreted as wait forever.

Santized both `retries` and initial `timeout` prop values in [b651829](https://github.com/openjdk/jdk/pull/20892/commits/b6518291f96244ce12ee1da1d9b740c4bd5b11f6)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752545380

From eirbjo at openjdk.org  Tue Sep 10 18:58:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 10 Sep 2024 18:58:41 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry
Message-ID: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>

Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 

`ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.

By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 

This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:

Baseline:


Benchmark                    (size)  Mode  Cnt   Score   Error  Units
ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op


PR:


Benchmark                    (size)  Mode  Cnt   Score   Error  Units
ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op


This purely a cleanup and optimization PR, no functional tests are changed or added.

-------------

Commit messages:
 - Avoid repeated checking of trailing slash in ZipFile.getZipEntry

Changes: https://git.openjdk.org/jdk/pull/20939/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339874
  Stats: 59 lines in 2 files changed: 17 ins; 21 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20939/head:pull/20939

PR: https://git.openjdk.org/jdk/pull/20939

From msheppar at openjdk.org  Tue Sep 10 19:04:05 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 10 Sep 2024 19:04:05 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <8gQI8QaHUU8Je6KG15-k-7IwYOw1GNQCZxkJ5UDTMVI=.ba34290b-92eb-4d60-af03-0d8c804c04e4@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
 <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
 <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>
 <8gQI8QaHUU8Je6KG15-k-7IwYOw1GNQCZxkJ5UDTMVI=.ba34290b-92eb-4d60-af03-0d8c804c04e4@github.com>
Message-ID: <Ma_5S4QCa5-k6jNnOQVg2LUXoqQCXg08d6MfNp_bC28=.19b9a405-c7fe-4225-b020-07d06aee35f4@github.com>

On Tue, 10 Sep 2024 18:38:15 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> I think 2 times is good, remove all potential noise  ;-)
>> 
>> the following failures is nearly twice the expected
>> 
>> ----------System.out:(3/73)----------
>> Skip local DNS Server creation
>> Elapsed (ms): 14229
>> Expected (ms): 7750
>> ----------System.err:(13/652)----------
>> java.lang.RuntimeException: Failed: timeout in 14229 ms, expected 7750ms
>> at Timeout.handleException(Timeout.java:116)
>> at TestBase.launch(TestBase.java:84)
>> at TestBase.run(TestBase.java:50)
>> at Timeout.main(Timeout.java:59)
>> 
>> and  I think it fails  the new upper bound check 
>> 
>> most of the elapsed times that have been less than the expected have been within the 50 * 5  tolerance, but there have been a few outside the -250 mess lower bound
>
> I agree that we don't want to document too much here. Updated the factor to 1.75 (2 seems a bit high and might hide real issues), and to make the timeout value calculation and check less arcane - I have updated test output to print the range of acceptable timeout values: 05ed9e053865293a1938ed7bc6fe208759513813

2 time  is not too high,
I have presented, in the comment, a failures with the elapsed time is almost twice the expected time
where the elapsed time is 14229 !! which is approx 1.84 * expected timeout

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752563030

From lancea at openjdk.org  Tue Sep 10 19:17:05 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 10 Sep 2024 19:17:05 GMT
Subject: RFR: 8339810: Clean up the code in sun.tools.jar.Main to properly
 close resources and use ZipFile during extract [v2]
In-Reply-To: <VWPJG0ZHvffuaWJ3MSifhSCX0HIfZVgfMT6YXsL6_9E=.1c634dc3-7208-4c74-bf9a-d35815dff400@github.com>
References: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
 <VWPJG0ZHvffuaWJ3MSifhSCX0HIfZVgfMT6YXsL6_9E=.1c634dc3-7208-4c74-bf9a-d35815dff400@github.com>
Message-ID: <asfBH1tRHmpCC_U1nE1usPeO5kMwDTLyf_UlYVb_rBI=.87b7e4b4-3112-40b6-b04b-5116803e33f8@github.com>

On Tue, 10 Sep 2024 06:17:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?
>> 
>> As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.
>> 
>> No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Christian's review - array declaration style

Hi Jai,

Thank you for the cleanup, I think the changes look good

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20928#pullrequestreview-2293563041

From bchristi at openjdk.org  Tue Sep 10 19:23:16 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 10 Sep 2024 19:23:16 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
Message-ID: <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>

> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
> 
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
> 
> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
> 
> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
> 
> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
> 
> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  add try-finally block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20898/files
  - new: https://git.openjdk.org/jdk/pull/20898/files/862d4da2..b2faf90e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20898&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20898&range=00-01

  Stats: 21 lines in 1 file changed: 3 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20898/head:pull/20898

PR: https://git.openjdk.org/jdk/pull/20898

From redestad at openjdk.org  Tue Sep 10 19:37:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 19:37:04 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <Nh-QxUwrAVb4rzOhFWxnCsXP8bDzjgJlbOVrF1Rpz2A=.c299f5a2-2fd0-4ad8-bd1d-c7807d35e8b1@github.com>

On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 161:

> 159:     }
> 160: 
> 161:     protected boolean hasTrailingSlash(byte[] a, int end) {

Why are you making these `protected`? `ZipCoder` is package-private so any inheritors must be in the same package, which means they already have access to package-private methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1752624971

From darcy at openjdk.org  Tue Sep 10 19:40:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Sep 2024 19:40:07 GMT
Subject: Integrated: 8339789: Use index and definition tags in AnnotatedElement
In-Reply-To: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
References: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
Message-ID: <oUrviryOncWX0Wfcl-LT3q_YQe3fBbkK4LWcEZFIwUg=.0c375e1f-a7cd-4b8e-babb-c43022963da9@github.com>

On Mon, 9 Sep 2024 18:37:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use index and definition tags in AnnotatedElement.

This pull request has now been integrated.

Changeset: 6fd043f1
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6fd043f1e4423b61cb5b85af9380f75e6a3846a2
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8339789: Use index and definition tags in AnnotatedElement

Reviewed-by: jjg, prappo

-------------

PR: https://git.openjdk.org/jdk/pull/20919

From redestad at openjdk.org  Tue Sep 10 19:42:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 19:42:04 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <Ma6bgDDava6XplyLhKbr5QAWdrMqlU08KR8_sCebisg=.ed8971a7-e59c-492a-b9f8-554adcc3e3e9@github.com>

On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

src/java.base/share/classes/java/util/zip/ZipFile.java line 681:

> 679: 
> 680:         e.flag = CENFLG(cen, pos);
> 681:         e.method = CENHOW(cen, pos);

Not reading `nlen` when it's not needed is a good change, and moving `clen` and `elen` down to be grouped with the others is fine, but some of the other shuffling around here doesn't seem motivated?

src/java.base/share/classes/java/util/zip/ZipFile.java line 1891:

> 1889:             // Return the position of "name/" if we found it
> 1890:             if (dirPos != -1) {
> 1891:                 return new EntryPos(name +"/", dirPos);

Suggestion:

                return new EntryPos(name + "/", dirPos);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1752630171
PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1752628607

From lancea at openjdk.org  Tue Sep 10 19:47:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 10 Sep 2024 19:47:06 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <4zLGcbWIwaZme7djDq4vYOsVzo182WHidSXdzFBIOE8=.2eae5ac4-b7a3-49a2-8c6d-78f647a2609f@github.com>

On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

Some initial thoughts but overall it seems to be a beneficial change.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 161:

> 159:     }
> 160: 
> 161:     protected boolean hasTrailingSlash(byte[] a, int end) {

Can you explain the need for this

src/java.base/share/classes/java/util/zip/ZipFile.java line 700:

> 698:         }
> 699:         if (clen != 0) {
> 700:             int nlen = CENNAM(cen, pos);

If this does not make a huge performance difference, I would keep this together with the init of elen and clen on line 692.

While there are not many  entry comments encountered, I do expect extra fields to somewhat common

-------------

PR Review: https://git.openjdk.org/jdk/pull/20939#pullrequestreview-2293604516
PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1752629986
PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1752620013

From naoto at openjdk.org  Tue Sep 10 19:50:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Sep 2024 19:50:13 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files
Message-ID: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>

This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/20940/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20940&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339803
  Stats: 41 lines in 4 files changed: 7 ins; 4 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/20940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20940/head:pull/20940

PR: https://git.openjdk.org/jdk/pull/20940

From bpb at openjdk.org  Tue Sep 10 19:58:48 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Sep 2024 19:58:48 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v6]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <YXA6_pJQmctqbCGtuy_bZntXf5TnqCRWbwwFC7jXZbs=.cfaeca45-e480-448e-a7aa-c7eb1f196cb0@github.com>

> 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 six commits:

 - 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
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05
  Stats: 1561 lines in 90 files changed: 771 ins; 674 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From redestad at openjdk.org  Tue Sep 10 20:00:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Sep 2024 20:00:10 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <T7nYrUW9P-eqxCauGRlSBLXjhK-qYoXaMFXeKGAElBs=.3cbed6af-92e3-4e5f-89a3-263a622a1f56@github.com>

On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

src/java.base/share/classes/java/util/zip/ZipFile.java line 549:

> 547:                 // each "entry" has 3 ints in table entries
> 548:                 int pos = res.zsrc.getEntryPos(i++ * 3);
> 549:                 return (T)getZipEntry(new EntryPos(getEntryName(pos), pos));

Do we have benchmarks covering the various types of iteration?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1752650407

From bpb at openjdk.org  Tue Sep 10 20:01:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Sep 2024 20:01:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>

On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:
> 
>> 573:      * Used to trigger loading of native libraries
>> 574:      */
>> 575:     public static void load() { }
> 
> do we still need this method?

Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752651246

From liach at openjdk.org  Tue Sep 10 20:06:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Sep 2024 20:06:14 GMT
Subject: RFR: 8339789: Use index and definition tags in AnnotatedElement
In-Reply-To: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
References: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
Message-ID: <csnsRfMlyFzudpwyODHCvMDdo0aQpNfM0PHyllPSvNk=.aa6d538e-b51f-46f4-8ab9-91f26215d781@github.com>

On Mon, 9 Sep 2024 18:37:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use index and definition tags in AnnotatedElement.

Just curious, if we have `{@index "type annotation"}`, does a search for `type annotation` in Javadoc search bar still work?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20919#issuecomment-2341912682

From lancea at openjdk.org  Tue Sep 10 20:12:07 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 10 Sep 2024 20:12:07 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <ONrGMOYOh2pEjfL_WgTDZy6SzlZPWu6tcdCjSg1MbzU=.2133be3b-0ee2-4353-8e14-7fa28a683958@github.com>

On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

I think the changes look reasonable and make sense.  Will need to an internal run as well for a sanity check.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20905#pullrequestreview-2293675629

From bchristi at openjdk.org  Tue Sep 10 20:14:07 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 10 Sep 2024 20:14:07 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>
Message-ID: <IVrn-xA8lE7NGbRV7GUbIOXUiNRV0fMXinC69dR60bw=.d420a867-eeb2-423b-935b-0e8634c69131@github.com>

On Tue, 10 Sep 2024 19:23:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
>> 
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
>> 
>> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
>> 
>> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
>> 
>> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
>> 
>> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add try-finally block

I've added a try/finally block for `ref`. I've also kept the `obj = null` assignment.

This test library is used in many places, to confirm behavior reliant on GC action. IMO it's best to code it in a way that's sure to behave as expected, and to keep it clear what it's meant to do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20898#issuecomment-2341922732

From bchristi at openjdk.org  Tue Sep 10 20:14:09 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 10 Sep 2024 20:14:09 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <6yn2UGscloAIQ9iyruHzAbL-uSypFtQClnlvS86G-YQ=.4a49fe1f-d22e-4302-a84a-a009236844c6@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <6yn2UGscloAIQ9iyruHzAbL-uSypFtQClnlvS86G-YQ=.4a49fe1f-d22e-4302-a84a-a009236844c6@github.com>
Message-ID: <tTu-7fL3vVgXVVZccv1yP1jdd0bcbAyJu0FOhNfC_Vk=.85eb816e-7af4-4529-99c3-bfd78c528cb0@github.com>

On Sat, 7 Sep 2024 00:59:25 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
>> 
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
>> 
>> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
>> 
>> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
>> 
>> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
>> 
>> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.
>
> I added a couple specific comments on the code that I thought ought to be addressed in this PR.
> 
> There is a broader issue with the timeout logic that we should be aware of, however, we might or might not choose to address it in this PR. The main issue is that the caller has requested a particular amount of time as the timeout, and the timeout loop divides by 200ms to determine the maximum number of retries. This _assumes_ that each loop will take 200ms. However, this might not be true, because we don't know how long the booleanSupplier takes, we don't know how long System.gc() takes, and we don't know how long queue.remove() takes. This isn't an idle concern. Somebody might pass in a booleanSupplier that itself has a timeout (say of 1 second) which will cause this method to take about six times longer than expected to time out.
> 
> The usual approach for timeout logic is to take the initial System.nanoTime() value and compare subsequent return values of nanoTime() to the timeout duration, and exit the loop if the timeout duration has been exceeded. See the nanoTime() javadoc for an example.

> The sketchy timeout handling mentioned by @stuart-marks seems to me to be out of scope for this issue.

I also would prefer that updates to timeout handling be done as a separate issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20898#issuecomment-2341925965

From vklang at openjdk.org  Tue Sep 10 21:01:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Sep 2024 21:01:24 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v2]
In-Reply-To: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
Message-ID: <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>

> This PR applies @AlanBateman's patch from the JBS issue.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Removing ThreadSleepEvent from stack trace checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20923/files
  - new: https://git.openjdk.org/jdk/pull/20923/files/64bb44a9..b4241e3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20923&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20923&range=00-01

  Stats: 11 lines in 3 files changed: 0 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20923/head:pull/20923

PR: https://git.openjdk.org/jdk/pull/20923

From liach at openjdk.org  Tue Sep 10 21:18:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Sep 2024 21:18:19 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v6]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - omission in tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Rename constants at new locations, link to related factories, cp tag constant names
 - Fix compile errors
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Compile errors; now tests are all green.
 - Move Constant Pool tags to PoolEntry
   
   Two unexpected usages in jlink raw processing, but rest is fine
 - ... and 4 more: https://git.openjdk.org/jdk/compare/6fd043f1...fa9ea36d

-------------

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=05
  Stats: 3473 lines in 37 files changed: 1566 ins; 901 del; 1006 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

PR: https://git.openjdk.org/jdk/pull/20773

From darcy at openjdk.org  Tue Sep 10 21:18:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Sep 2024 21:18:07 GMT
Subject: RFR: 8339789: Use index and definition tags in AnnotatedElement
In-Reply-To: <csnsRfMlyFzudpwyODHCvMDdo0aQpNfM0PHyllPSvNk=.aa6d538e-b51f-46f4-8ab9-91f26215d781@github.com>
References: <I2IyfhugeaT49oxENKI0QaHxjy7xVupMhfqV1_ILBaQ=.9a221337-7280-4086-8920-4c6887d7aa99@github.com>
 <csnsRfMlyFzudpwyODHCvMDdo0aQpNfM0PHyllPSvNk=.aa6d538e-b51f-46f4-8ab9-91f26215d781@github.com>
Message-ID: <1tLRQIRNWCm7n5DWIiazKlAt1TDXP256lSaSwqDCGtE=.31fdf89a-e5ab-43d4-b001-e2250f33b968@github.com>

On Tue, 10 Sep 2024 20:03:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> Just curious, if we have `{@index "type annotation"}`, does a search for `type annotation` in Javadoc search bar still work?

Yes; Javadoc search is fine returning multiple results. They are grouped by category with search terms like this appearing at the bottom.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20919#issuecomment-2342023418

From dholmes at openjdk.org  Tue Sep 10 21:34:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 21:34:04 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
Message-ID: <w_PBxIPDDrg4AUHHwHl79ygG4Fz80aywxLvYBxaNx9U=.5dd55890-3546-40c7-9da0-91b3dc27c6c1@github.com>

On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageToolTest too

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2293814493

From sviswanathan at openjdk.org  Tue Sep 10 21:36:09 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 10 Sep 2024 21:36:09 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v3]
In-Reply-To: <fiTWbCHS_pL8gkbMwSW9pLSzPhVD3TIAhiPxxM-E38A=.a191f89e-8a98-4ca5-bf7e-87bfb9009300@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <fiTWbCHS_pL8gkbMwSW9pLSzPhVD3TIAhiPxxM-E38A=.a191f89e-8a98-4ca5-bf7e-87bfb9009300@github.com>
Message-ID: <rJXxH_mcsDwUHxH-Gow5ewfw2tb48Y0SXEL8BctwTB8=.7e7581b9-80c0-43d8-9524-985be2467880@github.com>

On Thu, 5 Sep 2024 19:10:34 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update libm tanh reference test with code review suggestions

src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 810:

> 808:       x->id() == vmIntrinsics::_dpow || x->id() == vmIntrinsics::_dcos ||
> 809:       x->id() == vmIntrinsics::_dsin || x->id() == vmIntrinsics::_dtan ||
> 810:       x->id() == vmIntrinsics::_dlog10 || x->id() == vmIntrinsics::_dtanh) {

Need to have the tanh under #Ifdef _LP64 as we are generating stub only for 64 bit.

src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 1000:

> 998:        if (StubRoutines::dtanh() != nullptr) {
> 999:         __ call_runtime_leaf(StubRoutines::dtanh(), getThreadTemp(), result_reg, cc->args());
> 1000:       } // TODO: else clause?

You could instead have an assert here that StubRoutines::dtanh() is not null. Thereby no need for the else clause.

src/hotspot/cpu/x86/templateInterpreterGenerator_x86_32.cpp line 376:

> 374:   //        [ hi(arg) ]
> 375:   //
> 376:   if (kind == Interpreter::java_lang_math_tanh) {

Need to update the copyright year to 2024 in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1752286133
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1752289575
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1752304061

From ihse at openjdk.org  Tue Sep 10 21:45:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Sep 2024 21:45:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
Message-ID: <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>

On Tue, 10 Sep 2024 15:15:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113).
>
> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed.

And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752762279

From ihse at openjdk.org  Tue Sep 10 21:50:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Sep 2024 21:50:14 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com>
Message-ID: <DckGzEtnesPu5oN7E7KzLczbKhpQqaJGX0vQvtTSwHg=.0c3031b8-4738-4321-9295-5ac17f30de23@github.com>

On Tue, 10 Sep 2024 13:51:55 GMT, Josef Eisl <jeisl at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 135:
> 
>> 133: #endif
>> 134: 
>> 135:     if (!JVM_IsStaticallyLinked()) {
> 
> These "cross-library" link-type probes are a challenge for GraalVM native image. In native image, we statically link most standard JNI libraries into the final executable. However in some cases, for example AWT, static linking is not feasible due to their dependencies. Thus, we resort to dynamic linking. Have a mix of static and dynamic linking means that `JVM_IsStaticallyLinked` should give different answers based on the caller. Example:
> lets assume a follow-up change introduces a call to `JVM_IsStaticallyLinked` in libnet (which native image statically links):
> * if `JVM_IsStaticallyLinked` is called from libawt.so, we want to answer `false`
> * if `JVM_IsStaticallyLinked` is called from libnet.a, we want to answer `true`
> 
> Is the mixed linking use case is something that the Hermetic Java effort is having on its radar?
> 
> For this particular case, one solutions could be to avoid cross-library calls. I.e., instead of calling `JVM_IsStaticallyLinked`, have an `AWT_IsStaticallyLinked` that is local to the libawt. This is similar to the pattern also used for JLI.

Mixing static and dynamic libraries willy-nilly sounds like a situation that is hard to resolve in a safe and sound way. The basic assumption here has been that you either have all libraries dynamic, or all libraries static.

In the particular case you mention about libawt, I think the proper solution is to sort out the mess that is libawt_headless/libawt_xawt. It seems to me that the X support should be loaded using dlopen, not by hard dependencies to the X libraries. I think that should solve your problem (as well as many other problems).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1752767100

From jlu at openjdk.org  Tue Sep 10 22:20:07 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Sep 2024 22:20:07 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files
In-Reply-To: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
Message-ID: <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com>

On Tue, 10 Sep 2024 19:45:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1375:

> 1373:         Files.walk(Path.of(tzDataDir), 1, FileVisitOption.FOLLOW_LINKS)
> 1374:             .filter(p -> p.toFile().isFile())
> 1375:             .filter(p -> p.getFileName().toString().matches("africa|antarctica|asia|australasia|backward|backzone|etcetera|europe|factory|northamerica|southamerica"))

I am just curious, why is this needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1752828774

From naoto at openjdk.org  Tue Sep 10 22:42:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Sep 2024 22:42:37 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
Message-ID: <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>

> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  tz files aligned with the default TzdbZoneRulesProvider list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20940/files
  - new: https://git.openjdk.org/jdk/pull/20940/files/264d5772..423720c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20940&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20940&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20940/head:pull/20940

PR: https://git.openjdk.org/jdk/pull/20940

From naoto at openjdk.org  Tue Sep 10 22:42:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Sep 2024 22:42:37 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com>
Message-ID: <Bw-ZWDH1tus40XAepjBUS7_HzFEQxW6wJicjM4pNdUQ=.735678bf-148d-40b1-80e0-d9e95d006ec5@github.com>

On Tue, 10 Sep 2024 22:17:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tz files aligned with the default TzdbZoneRulesProvider list
>
> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1375:
> 
>> 1373:         Files.walk(Path.of(tzDataDir), 1, FileVisitOption.FOLLOW_LINKS)
>> 1374:             .filter(p -> p.toFile().isFile())
>> 1375:             .filter(p -> p.getFileName().toString().matches("africa|antarctica|asia|australasia|backward|backzone|etcetera|europe|factory|northamerica|southamerica"))
> 
> I am just curious, why is this needed?

It would otherwise scan all files under the directory, and fails with `iso3166.tab` or `zone.tab`, which include "LI" as the country code at the beginning of the line, that interfere with "Link" match.
Having said that, the default list was different from the one in `TzdbZoneRulesProvider`. I removed extra file names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1752889391

From jlu at openjdk.org  Tue Sep 10 22:56:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Sep 2024 22:56:05 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
Message-ID: <H1d0khjhkGMzQmsrLyXRlW3JTqX6UWXfsFJkfc8gG64=.f5857e94-1c06-4a8a-bdea-cbfa8796a7b5@github.com>

On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tz files aligned with the default TzdbZoneRulesProvider list

Looks good to me

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20940#pullrequestreview-2294103087

From jlu at openjdk.org  Tue Sep 10 22:56:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Sep 2024 22:56:06 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <Bw-ZWDH1tus40XAepjBUS7_HzFEQxW6wJicjM4pNdUQ=.735678bf-148d-40b1-80e0-d9e95d006ec5@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com>
 <Bw-ZWDH1tus40XAepjBUS7_HzFEQxW6wJicjM4pNdUQ=.735678bf-148d-40b1-80e0-d9e95d006ec5@github.com>
Message-ID: <enLLUIcED4VWW9APfQ88Gm436gw-1knU-19jeu7PkaY=.0d1ad434-9e7c-473d-be5a-a3bdad8dfaed@github.com>

On Tue, 10 Sep 2024 22:39:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1375:
>> 
>>> 1373:         Files.walk(Path.of(tzDataDir), 1, FileVisitOption.FOLLOW_LINKS)
>>> 1374:             .filter(p -> p.toFile().isFile())
>>> 1375:             .filter(p -> p.getFileName().toString().matches("africa|antarctica|asia|australasia|backward|backzone|etcetera|europe|factory|northamerica|southamerica"))
>> 
>> I am just curious, why is this needed?
>
> It would otherwise scan all files under the directory, and fails with `iso3166.tab` or `zone.tab`, which include "LI" as the country code at the beginning of the line, that interfere with "Link" match.
> Having said that, the default list was different from the one in `TzdbZoneRulesProvider`. I removed extra file names.

Right, the match in general is much more lenient now, so need to restrict the files searched for false positives. Thanks for the explanation, that makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1752897921

From naoto at openjdk.org  Tue Sep 10 23:15:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Sep 2024 23:15:04 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <H1d0khjhkGMzQmsrLyXRlW3JTqX6UWXfsFJkfc8gG64=.f5857e94-1c06-4a8a-bdea-cbfa8796a7b5@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
 <H1d0khjhkGMzQmsrLyXRlW3JTqX6UWXfsFJkfc8gG64=.f5857e94-1c06-4a8a-bdea-cbfa8796a7b5@github.com>
Message-ID: <dGyHN1q_SJHidvUd58QbGKme1ZlYIr7T4OIaEapEaWI=.8366be79-e3ca-4155-b42c-3aedc310f8f9@github.com>

On Tue, 10 Sep 2024 22:53:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tz files aligned with the default TzdbZoneRulesProvider list
>
> Looks good to me

Thanks, @justin-curtis-lu. @coffeys, would you please review this PR, which can also apply to the tzupdater tool?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2342318673

From liach at openjdk.org  Tue Sep 10 23:29:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Sep 2024 23:29:12 GMT
Subject: RFR: 8339875: MethodTypeDesc to reuse descriptor string from
 MethodType
Message-ID: <Xfdaa5WawpEz-f0wBiePT3ndXxp-vCD8ap-06JfNf0A=.8c54b7f4-f059-4109-b954-3fc80ad1c2bf@github.com>

A micro-optimization by sharing compatible String objects from MethodType (which itself is already deduplicated in a cache) to the generated MethodTypeDesc. This very slightly improves hashing performance by avoiding some string creation, hashing, and fast path equality via identity.

-------------

Commit messages:
 - 8339875: MethodTypeDesc to reuse descriptor string from MethodType

Changes: https://git.openjdk.org/jdk/pull/20942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339875
  Stats: 49 lines in 7 files changed: 24 ins; 12 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20942/head:pull/20942

PR: https://git.openjdk.org/jdk/pull/20942

From duke at openjdk.org  Wed Sep 11 00:29:30 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Sep 2024 00:29:30 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v4]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <Zvt0oBc6PixHG-jBP_bYY43luNYFx7EaKavguoRhVU4=.73b88f9d-394f-4aca-ac1c-456771cf3ca3@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  c1 and template generator fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/39350a37..4aa52bfd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=02-03

  Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From duke at openjdk.org  Wed Sep 11 00:29:30 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Sep 2024 00:29:30 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v3]
In-Reply-To: <rJXxH_mcsDwUHxH-Gow5ewfw2tb48Y0SXEL8BctwTB8=.7e7581b9-80c0-43d8-9524-985be2467880@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <fiTWbCHS_pL8gkbMwSW9pLSzPhVD3TIAhiPxxM-E38A=.a191f89e-8a98-4ca5-bf7e-87bfb9009300@github.com>
 <rJXxH_mcsDwUHxH-Gow5ewfw2tb48Y0SXEL8BctwTB8=.7e7581b9-80c0-43d8-9524-985be2467880@github.com>
Message-ID: <0BMvrr-HLplOb73v8G3cdcG063jjNDkkBlCCnH8MH9c=.d7f172bf-750d-4ba4-840f-d2f492cac2c9@github.com>

On Tue, 10 Sep 2024 16:26:38 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update libm tanh reference test with code review suggestions
>
> src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 810:
> 
>> 808:       x->id() == vmIntrinsics::_dpow || x->id() == vmIntrinsics::_dcos ||
>> 809:       x->id() == vmIntrinsics::_dsin || x->id() == vmIntrinsics::_dtan ||
>> 810:       x->id() == vmIntrinsics::_dlog10 || x->id() == vmIntrinsics::_dtanh) {
> 
> Need to have the tanh under #Ifdef _LP64 as we are generating stub only for 64 bit.

Please see the newly added `#ifdef `in the updated code.

> src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 1000:
> 
>> 998:        if (StubRoutines::dtanh() != nullptr) {
>> 999:         __ call_runtime_leaf(StubRoutines::dtanh(), getThreadTemp(), result_reg, cc->args());
>> 1000:       } // TODO: else clause?
> 
> You could instead have an assert here that StubRoutines::dtanh() is not null. Thereby no need for the else clause.

Please see the newly added assert in the updated code.

> src/hotspot/cpu/x86/templateInterpreterGenerator_x86_32.cpp line 376:
> 
>> 374:   //        [ hi(arg) ]
>> 375:   //
>> 376:   if (kind == Interpreter::java_lang_math_tanh) {
> 
> Need to update the copyright year to 2024 in this file.

Please see the year updated to 2024 in the updated code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1752962967
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1752962670
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1752963446

From jpai at openjdk.org  Wed Sep 11 01:22:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 01:22:12 GMT
Subject: RFR: 8339810: Clean up the code in sun.tools.jar.Main to properly
 close resources and use ZipFile during extract [v2]
In-Reply-To: <VWPJG0ZHvffuaWJ3MSifhSCX0HIfZVgfMT6YXsL6_9E=.1c634dc3-7208-4c74-bf9a-d35815dff400@github.com>
References: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
 <VWPJG0ZHvffuaWJ3MSifhSCX0HIfZVgfMT6YXsL6_9E=.1c634dc3-7208-4c74-bf9a-d35815dff400@github.com>
Message-ID: <FDNEE61KCPt4Mwux4qywMwKDDd9oLk-TbKwZltY26SQ=.3bed2df1-d5ee-4f45-928c-45d46959b01d@github.com>

On Tue, 10 Sep 2024 06:17:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?
>> 
>> As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.
>> 
>> No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Christian's review - array declaration style

Thank you for the reviews, Christian and Lance. I'll go ahead and integrate this shortly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20928#issuecomment-2342429770

From darcy at openjdk.org  Wed Sep 11 02:02:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Sep 2024 02:02:13 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
 <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
Message-ID: <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>

On Thu, 5 Sep 2024 19:10:08 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> test/jdk/java/lang/Math/HyperbolicTests.java line 1009:
>> 
>>> 1007:         for(int i = 0; i < testCases.length; i++) {
>>> 1008:             double testCase = testCases[i];
>>> 1009:             failures += testTanhWithReferenceUlpDiff(testCase, StrictMath.tanh(testCase), 2.5);
>> 
>> The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.
>> 
>> For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).
>> 
>> If the test is going to use randomness, then its jtreg tags should include
>> 
>> `@key randomness`
>> 
>> and it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.
>
>> If the test is going to use randomness, then its jtreg tags should include
>> 
>> `@key randomness`
>> 
>> and it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.
> 
> Please see the test updated to use `@key randomness` and` jdk.test.lib.RandomFactory` to get and Random object.
> 
>> The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.
>> For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).
>>
> So far the tests haven't failed with error of 2.5ulp. Would it be better to make it 5ulp? Please let me know.

So far, this will be the only intrinsic implementation of tanh. Therefore, at the moment it is just checking the consistency of the intrinsic implementation with StrictMath/FDLIBM tanh. If the intrinsic has a ~1 ulp accuracy, it would be expected to often be within 2.5 ulps of FDLIBM tanh. However, as written the regression test would not necessarily pass against any allowable Math.tanh implementation, which is the usual criteria for java.lang.Math tests that aren't otherwise constrained (such as by being limited to a given subset of platforms).

If there was a correctly rounded tanh to compare against, then this style of testing would be valid.

Are there any plan to intrinsify sinh or cosh?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1753010811

From dholmes at openjdk.org  Wed Sep 11 02:12:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Sep 2024 02:12:04 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>
Message-ID: <WdiJBfIXf6oW_OBKI9QvP8giIyTfTADQ-kI75NLsDW4=.00d7c868-eda7-4750-946e-2db8ef932430@github.com>

On Tue, 10 Sep 2024 19:23:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
>> 
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
>> 
>> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
>> 
>> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
>> 
>> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
>> 
>> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add try-finally block

If you hide whitespace this change becomes trivial to review :)

LGTM.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20898#pullrequestreview-2294914217

From syan at openjdk.org  Wed Sep 11 02:15:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Sep 2024 02:15:14 GMT
Subject: Integrated: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <ArCSFJ2NhaV5Nou8fOnBLDgQkIawYjH2S_ThfsUoK40=.51a02083-2dcd-4446-98bd-156885d41241@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

This pull request has now been integrated.

Changeset: a6faf824
Author:    SendaoYan <syan at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6faf8247b58d73dca199fe1e8b0e914c415f67f
Stats:     14 lines in 2 files changed: 1 ins; 12 del; 1 mod

8339714: Delete tedious bool type define

Reviewed-by: jwaters, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/20909

From syan at openjdk.org  Wed Sep 11 02:30:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Sep 2024 02:30:10 GMT
Subject: RFR: 8339714: Delete tedious bool type define
In-Reply-To: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
References: <N_dxsOPuTX_qO9BQU7OaF0ZBFXAFzY5Q-PWJPHPWpJc=.ec19cfd6-2d89-47a0-ae31-58de870c165a@github.com>
Message-ID: <6wPZ40cgyH7U6kJN31R80qymYXzQwTX-ndD-2MKboo0=.9178e030-415a-4b5d-8e13-a298e03e9c4f@github.com>

On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include <stdbool.h>" to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do.
>   Make code more concision, the risk is quite low.
> 
> Additional testing:
> 
> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64
> - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64

Thanks for the sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2342489060

From dholmes at openjdk.org  Wed Sep 11 02:31:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Sep 2024 02:31:04 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v2]
In-Reply-To: <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
Message-ID: <8VTdtkMX4R3x61e7MD36nnvnxpo_RR8-jg7J71KWLyQ=.a003d4a9-12c4-49dd-aaad-e467f5ba2003@github.com>

On Tue, 10 Sep 2024 21:01:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing ThreadSleepEvent from stack trace checks

With regards to the nsk tests, are `beforeSleep` and `afterSleep` still potential candidates now that it is impossible for them to throw OOME?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20923#pullrequestreview-2294994911

From duke at openjdk.org  Wed Sep 11 03:25:07 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 11 Sep 2024 03:25:07 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v6]
In-Reply-To: <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>
Message-ID: <GyLlV8FR8fcBpsQBOzL6BmFsWJowFUAspSVregDDi24=.21e4a94e-4a5b-4b8e-b69c-5f5a58baf6ff@github.com>

On Tue, 10 Sep 2024 21:18:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - omission in tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Rename constants at new locations, link to related factories, cp tag constant names
>  - Fix compile errors
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Compile errors; now tests are all green.
>  - Move Constant Pool tags to PoolEntry
>    
>    Two unexpected usages in jlink raw processing, but rest is fine
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6fd043f1...fa9ea36d

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationBytecodes.java line 92:

> 90:             case ClassFile.WIDE:
> 91:             case ClassFile.TABLESWITCH:
> 92:             case ClassFile.LOOKUPSWITCH:

This?method was?removed in?[JDK?8339576] ([GH?20863]):
Suggestion:



[JDK?8339576]: https://bugs.openjdk.org/browse/JDK-8339576
[GH?20863]: https://github.com/openjdk/jdk/pull/20863

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 1427:

> 1425:         int keys, delta;
> 1426:         current_frame.pop_stack(VerificationType.integer_type);
> 1427:         if (bcs.rawCode == ClassFile.TABLESWITCH) {

Suggestion:

        if (bcs.rawCode == TABLESWITCH) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1753066336
PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1753066484

From miiiinju00 at gmail.com  Wed Sep 11 04:33:03 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Wed, 11 Sep 2024 13:33:03 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
Message-ID: <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>

Hi Archie and Viktor,

I apologize for the delay in my response.



After further consideration, I believe my understanding aligns more closely with Interpretation B.

To clarify my understanding of Interpretation B, threads waiting on a Condition (linked through ConditionNode in ConditionObject) receive signals in the order in which they started waiting, but receiving a signal doesn't guarantee immediate reacquisition of the ReentrantLock. Instead, as far as I understand, the signal simply enqueues the thread at the end of the AQS queue(ReentrantLock).



As a result, threads that received a signal from ConditionObject do not have priority over the threads already waiting in the AQS queue and are simply added to the end of that queue.

From what I understand, the difference between NonFairSync and FairSync lies in whether a thread can acquire the lock when there are other threads already waiting in the AQS queue, rather than anything related to the threads signaled from a Condition.



Additionally, as I understand it, the enqueue() and doSignal() methods are declared final in AQS, and both Syncimplementations use the AQS methods directly.



Therefore, I wanted to highlight that this isn't necessarily an issue with AQS or FairSync. Instead, I suspect that the behavior we're seeing could arise from the fact that threads signaled in a BlockingQueue implementation may not execute immediately, which is a characteristic of the implementation.



However, there may be aspects I?m misunderstanding, and I would appreciate any corrections or clarifications if that?s the case.



Thank you very much for your time and understanding.

Best regards,

Kim Minju


> 2024. 9. 8. ?? 11:39, Archie Cobbs <archie.cobbs at gmail.com> ??:
> 
> Hi Kim,
> 
> Thanks for the details.
> 
> So to summarize:
> Kim is saying that "Interpretation B" is how it actually works.
> Viktor is saying that "Interpretation A" is how it actually works.
> Do I have that right?
> 
> -Archie
> 
> P.S. Viktor: my apologies for misspelling your name before
> 
> 
> On Sat, Sep 7, 2024 at 8:04?PM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>> Hi Arhice,
>> 
>> 
>> 
>> First of all, I want to apologize if I may not have explained things clearly since English is not my first language. I?m really sorry about that.
>> 
>> 
>> 
>> Even so, I deeply appreciate your response and taking the time to reply.
>> 
>> 
>> 
>> First, I would like to confirm whether my understanding is correct.
>> 
>> From what I know, ReentrantLock is based on AQS, and internally, threads are queued by being linked as Node.
>> 
>> When ReentrantLock.newCondition is called, a ConditionObject is created. When Condition::await is called, the thread waits based on a ConditionNode, and the AQS head is replaced with AQS::signalNext, allowing the lock to be released. At this point, I understand that the node disappears from the AQS queue and starts waiting within the ConditionNode of the ConditionObject.
>> 
>> As a result, I understand that the waiting places for ReentrantLock and Condition are different.
>> 
>> To summarize, when Condition::await() is called, the node that was previously waiting in AQS receives the lock, disappears from the AQS queue, and starts waiting within the ConditionNode of the ConditionObject.
>> 
>> Additionally, from what I understand, in Condition::doSignal, the first ConditionNode is removed, and then AQS::enqueue adds it to the tail of AQS.
>> 
>> public class ConditionObject implements Condition, java.io.Serializable {
>> 
>> private void doSignal(ConditionNode first, boolean all) {
>>     while (first != null) {
>>         ConditionNode next = first.nextWaiter;
>>         if ((firstWaiter = next) == null)
>>             lastWaiter = null;
>>         if ((first.getAndUnsetStatus(COND) & COND) != 0) {
>>             enqueue(first);
>>             if (!all)
>>                 break;
>>         }
>>         first = next;
>>     }
>> }
>> 
>> When enqueue is called:
>> 
>> public abstract class AbstractQueuedSynchronizer
>>     extends AbstractOwnableSynchronizer
>> 
>>     /*
>>      * Tail of the wait queue. After initialization, modified only via casTail.
>>      */
>>     private transient volatile Node tail;
>> 
>> 	 final void enqueue(Node node) {
>> 	    if (node != null) {
>> 	        for (;;) {
>> 	            Node t = tail;
>> 	            node.setPrevRelaxed(t);        // avoid unnecessary fence
>> 	            if (t == null)                 // initialize
>> 	                tryInitializeHead();
>> 	            else if (casTail(t, node)) {
>> 	                t.next = node;
>> 	                if (t.status < 0)          // wake up to clean link
>> 	                    LockSupport.unpark(node.waiter);
>> 	                break;
>> 	            }
>> 	        }
>> 	    }
>> }
>> 
>> From my understanding, this attaches the node to the tail of AQS.
>> 
>> To elaborate further on the situation:
>> 
>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>> 
>> (At this point, T1 to T10 are linked through ConditionNode.) [The AQS queue is empty, while ConditionNode holds T1 to T10.]
>> 
>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>> 
>> (Since no threads are waiting in the AQS queue, T11 will acquire the lock immediately.)
>> 
>> [Now, AQS holds T11 at its head, and ConditionNode holds T1 to T10.]
>> 
>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (Since T11 is holding the lock with take(), T12 will be queued behind it in AQS.)
>> 
>> [Now, AQS holds T11 and T12, while ConditionNode holds T1 to T10.]
>> 
>> T11 reduces the count and sends a signal, then releases the lock.
>> 
>> T1 receives the signal and moves to the lock queue. Since ReentrantLock is in fair mode,
>> 
>> (When T11 sends the signal, T1, the first thread linked in ConditionNode, will be enqueued via AQS::enqueue. Now, AQS holds T11, T12, and T1, while ConditionNode holds T2 to T10.)
>> 
>> T11 releases the lock and wakes up T12.
>> 
>> [Now, AQS holds T12 and T1, while ConditionNode holds T2 to T10.]
>> 
>> T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without being blocked by while(count==length).
>> 
>> T12 releases the lock, and the next node in AQS is unparked.
>> 
>> [Now, AQS holds T1, while ConditionNode holds T2 to T10.]
>> 
>> T1, having reacquired the lock after Condition::await(), fails to exit the while loop and waits again.
>> 
>> [Now, ConditionNode holds T1 and T2 to T10.]
>> 
>> 
>> 
>> This is how I currently understand the situation.
>> 
>> If there are any mistakes in my understanding, I would greatly appreciate your clarification.
>> 
>> Best Regards,
>> 
>>  Kim Minju
>> 
>> 
>>> 2024. 9. 8. ?? 3:34, Archie Cobbs <archie.cobbs at gmail.com <mailto:archie.cobbs at gmail.com>> ??:
>>> 
>>> Hi Kim,
>>> 
>>> On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>>>> Here's a clearer outline of the scenario:
>>>> 
>>>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>>>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>>>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (As I understand, the wait queue for ReentrantLock and Condition are separate.)
>>>> T11 reduces the count and sends a signal, then releases the lock.
>>>> T1 receives the signal and moves to the lock queue. Since the ReentrantLock is in fair mode, T12 (which was already waiting) gets priority, and T1 will acquire the lock later.
>>>> T12 acquires the lock and successfully enqueues.
>>> From one reading of the Javadoc, your step #5 ("T12 gets priority") is not supposed to happen that way. Instead, one of T1 through T10 should be guaranteed to acquire the lock.
>>> 
>>> Here it is again (from ReentrantLock.newCondition()):
>>> 
>>>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
>>> 
>>> 
>>> But part of the problem here is that this documentation is ambiguous.
>>> 
>>> The ambiguity is: are ALL threads trying to acquire the lock, whether on an initial attempt or after a condition wakeup, ordered for fairness together in one big pool? ? In this case step #5 can't happen. Call this Interpretation A.
>>> 
>>> Or is this merely saying that threads waiting on a condition reacquire the lock based on when they started waiting on the condition, but there are no ordering guarantees between those threads and any other unrelated threads trying to acquire the lock? ? In this case step #5 can happen. Call this Interpretation B.
>>> 
>>> So I think we first need to clarify which interpretation is correct here, A or B.
>>> 
>>> On that point, Victor said this:
>>> 
>>>> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge".
>>> 
>>> 
>>> So it sounds like Victor is confirming interpretation A. Victor do you agree?
>>> 
>>> If so, then it seems like we need to do two things:
>>> 
>>> 1. File a Jira ticket to clarify the Javadoc, e.g. to say something like this:
>>> 
>>>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest. In the latter case, the ordering consideration includes all threads attempting to acquire the lock, regardless of whether or not they were previously blocked on the condition.
>>> 
>>> 
>>> 2. Understand why Kim's updated test case is still failing (it must be either a bug in the test or a bug in ArrayBlockingQueue).
>>> 
>>> -Archie
>>> 
>>> --
>>> Archie L. Cobbs
>> 
> 
> 
> --
> Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240911/eb8d0715/attachment-0001.htm>

From miiiinju00 at gmail.com  Wed Sep 11 04:33:03 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Wed, 11 Sep 2024 13:33:03 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
Message-ID: <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>

Hi Archie and Viktor,

I apologize for the delay in my response.



After further consideration, I believe my understanding aligns more closely with Interpretation B.

To clarify my understanding of Interpretation B, threads waiting on a Condition (linked through ConditionNode in ConditionObject) receive signals in the order in which they started waiting, but receiving a signal doesn't guarantee immediate reacquisition of the ReentrantLock. Instead, as far as I understand, the signal simply enqueues the thread at the end of the AQS queue(ReentrantLock).



As a result, threads that received a signal from ConditionObject do not have priority over the threads already waiting in the AQS queue and are simply added to the end of that queue.

From what I understand, the difference between NonFairSync and FairSync lies in whether a thread can acquire the lock when there are other threads already waiting in the AQS queue, rather than anything related to the threads signaled from a Condition.



Additionally, as I understand it, the enqueue() and doSignal() methods are declared final in AQS, and both Syncimplementations use the AQS methods directly.



Therefore, I wanted to highlight that this isn't necessarily an issue with AQS or FairSync. Instead, I suspect that the behavior we're seeing could arise from the fact that threads signaled in a BlockingQueue implementation may not execute immediately, which is a characteristic of the implementation.



However, there may be aspects I?m misunderstanding, and I would appreciate any corrections or clarifications if that?s the case.



Thank you very much for your time and understanding.

Best regards,

Kim Minju


> 2024. 9. 8. ?? 11:39, Archie Cobbs <archie.cobbs at gmail.com> ??:
> 
> Hi Kim,
> 
> Thanks for the details.
> 
> So to summarize:
> Kim is saying that "Interpretation B" is how it actually works.
> Viktor is saying that "Interpretation A" is how it actually works.
> Do I have that right?
> 
> -Archie
> 
> P.S. Viktor: my apologies for misspelling your name before
> 
> 
> On Sat, Sep 7, 2024 at 8:04?PM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>> Hi Arhice,
>> 
>> 
>> 
>> First of all, I want to apologize if I may not have explained things clearly since English is not my first language. I?m really sorry about that.
>> 
>> 
>> 
>> Even so, I deeply appreciate your response and taking the time to reply.
>> 
>> 
>> 
>> First, I would like to confirm whether my understanding is correct.
>> 
>> From what I know, ReentrantLock is based on AQS, and internally, threads are queued by being linked as Node.
>> 
>> When ReentrantLock.newCondition is called, a ConditionObject is created. When Condition::await is called, the thread waits based on a ConditionNode, and the AQS head is replaced with AQS::signalNext, allowing the lock to be released. At this point, I understand that the node disappears from the AQS queue and starts waiting within the ConditionNode of the ConditionObject.
>> 
>> As a result, I understand that the waiting places for ReentrantLock and Condition are different.
>> 
>> To summarize, when Condition::await() is called, the node that was previously waiting in AQS receives the lock, disappears from the AQS queue, and starts waiting within the ConditionNode of the ConditionObject.
>> 
>> Additionally, from what I understand, in Condition::doSignal, the first ConditionNode is removed, and then AQS::enqueue adds it to the tail of AQS.
>> 
>> public class ConditionObject implements Condition, java.io.Serializable {
>> 
>> private void doSignal(ConditionNode first, boolean all) {
>>     while (first != null) {
>>         ConditionNode next = first.nextWaiter;
>>         if ((firstWaiter = next) == null)
>>             lastWaiter = null;
>>         if ((first.getAndUnsetStatus(COND) & COND) != 0) {
>>             enqueue(first);
>>             if (!all)
>>                 break;
>>         }
>>         first = next;
>>     }
>> }
>> 
>> When enqueue is called:
>> 
>> public abstract class AbstractQueuedSynchronizer
>>     extends AbstractOwnableSynchronizer
>> 
>>     /*
>>      * Tail of the wait queue. After initialization, modified only via casTail.
>>      */
>>     private transient volatile Node tail;
>> 
>> 	 final void enqueue(Node node) {
>> 	    if (node != null) {
>> 	        for (;;) {
>> 	            Node t = tail;
>> 	            node.setPrevRelaxed(t);        // avoid unnecessary fence
>> 	            if (t == null)                 // initialize
>> 	                tryInitializeHead();
>> 	            else if (casTail(t, node)) {
>> 	                t.next = node;
>> 	                if (t.status < 0)          // wake up to clean link
>> 	                    LockSupport.unpark(node.waiter);
>> 	                break;
>> 	            }
>> 	        }
>> 	    }
>> }
>> 
>> From my understanding, this attaches the node to the tail of AQS.
>> 
>> To elaborate further on the situation:
>> 
>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>> 
>> (At this point, T1 to T10 are linked through ConditionNode.) [The AQS queue is empty, while ConditionNode holds T1 to T10.]
>> 
>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>> 
>> (Since no threads are waiting in the AQS queue, T11 will acquire the lock immediately.)
>> 
>> [Now, AQS holds T11 at its head, and ConditionNode holds T1 to T10.]
>> 
>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (Since T11 is holding the lock with take(), T12 will be queued behind it in AQS.)
>> 
>> [Now, AQS holds T11 and T12, while ConditionNode holds T1 to T10.]
>> 
>> T11 reduces the count and sends a signal, then releases the lock.
>> 
>> T1 receives the signal and moves to the lock queue. Since ReentrantLock is in fair mode,
>> 
>> (When T11 sends the signal, T1, the first thread linked in ConditionNode, will be enqueued via AQS::enqueue. Now, AQS holds T11, T12, and T1, while ConditionNode holds T2 to T10.)
>> 
>> T11 releases the lock and wakes up T12.
>> 
>> [Now, AQS holds T12 and T1, while ConditionNode holds T2 to T10.]
>> 
>> T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without being blocked by while(count==length).
>> 
>> T12 releases the lock, and the next node in AQS is unparked.
>> 
>> [Now, AQS holds T1, while ConditionNode holds T2 to T10.]
>> 
>> T1, having reacquired the lock after Condition::await(), fails to exit the while loop and waits again.
>> 
>> [Now, ConditionNode holds T1 and T2 to T10.]
>> 
>> 
>> 
>> This is how I currently understand the situation.
>> 
>> If there are any mistakes in my understanding, I would greatly appreciate your clarification.
>> 
>> Best Regards,
>> 
>>  Kim Minju
>> 
>> 
>>> 2024. 9. 8. ?? 3:34, Archie Cobbs <archie.cobbs at gmail.com <mailto:archie.cobbs at gmail.com>> ??:
>>> 
>>> Hi Kim,
>>> 
>>> On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>>>> Here's a clearer outline of the scenario:
>>>> 
>>>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>>>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>>>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (As I understand, the wait queue for ReentrantLock and Condition are separate.)
>>>> T11 reduces the count and sends a signal, then releases the lock.
>>>> T1 receives the signal and moves to the lock queue. Since the ReentrantLock is in fair mode, T12 (which was already waiting) gets priority, and T1 will acquire the lock later.
>>>> T12 acquires the lock and successfully enqueues.
>>> From one reading of the Javadoc, your step #5 ("T12 gets priority") is not supposed to happen that way. Instead, one of T1 through T10 should be guaranteed to acquire the lock.
>>> 
>>> Here it is again (from ReentrantLock.newCondition()):
>>> 
>>>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
>>> 
>>> 
>>> But part of the problem here is that this documentation is ambiguous.
>>> 
>>> The ambiguity is: are ALL threads trying to acquire the lock, whether on an initial attempt or after a condition wakeup, ordered for fairness together in one big pool? ? In this case step #5 can't happen. Call this Interpretation A.
>>> 
>>> Or is this merely saying that threads waiting on a condition reacquire the lock based on when they started waiting on the condition, but there are no ordering guarantees between those threads and any other unrelated threads trying to acquire the lock? ? In this case step #5 can happen. Call this Interpretation B.
>>> 
>>> So I think we first need to clarify which interpretation is correct here, A or B.
>>> 
>>> On that point, Victor said this:
>>> 
>>>> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge".
>>> 
>>> 
>>> So it sounds like Victor is confirming interpretation A. Victor do you agree?
>>> 
>>> If so, then it seems like we need to do two things:
>>> 
>>> 1. File a Jira ticket to clarify the Javadoc, e.g. to say something like this:
>>> 
>>>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest. In the latter case, the ordering consideration includes all threads attempting to acquire the lock, regardless of whether or not they were previously blocked on the condition.
>>> 
>>> 
>>> 2. Understand why Kim's updated test case is still failing (it must be either a bug in the test or a bug in ArrayBlockingQueue).
>>> 
>>> -Archie
>>> 
>>> --
>>> Archie L. Cobbs
>> 
> 
> 
> --
> Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240911/eb8d0715/attachment-0003.htm>

From smarks at openjdk.org  Wed Sep 11 05:02:09 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 11 Sep 2024 05:02:09 GMT
Subject: RFR: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC [v2]
In-Reply-To: <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
 <-7rBVcVVXGmb9u52cbC69gziGCfoNnONkWqbHM2uiQ8=.0a628df7-1b50-4831-8768-0501e9bca8e1@github.com>
Message-ID: <IA3hQ3xMPPEQK-d121q1LJ96zDE-VIXdEJTYcwmY3zo=.ebeaee8a-3b6e-4c65-ae22-063907eb9f7a@github.com>

On Tue, 10 Sep 2024 19:23:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
>> 
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
>> 
>> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
>> 
>> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
>> 
>> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
>> 
>> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add try-finally block

Yeah, timeout stuff can be handled separately.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20898#pullrequestreview-2295462917

From jpai at openjdk.org  Wed Sep 11 05:30:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 05:30:09 GMT
Subject: Integrated: 8339810: Clean up the code in sun.tools.jar.Main to
 properly close resources and use ZipFile during extract
In-Reply-To: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
References: <Ck_hGPwfSvQXj6WeArPgQCFRo-NMq8OV-Y2GPGJ1HLs=.f48f441c-c2cd-492b-8067-1e5fe6798371@github.com>
Message-ID: <uZHUwaLs1fySqJLlUd81G_F-vS5Q8v_ak3rHb50DYzU=.02a48180-195d-4274-b170-7f17346edac9@github.com>

On Tue, 10 Sep 2024 05:31:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8339810?
> 
> As noted in the issue we have a few places in the jar's tool `Main` class where we currently don't close the resources in a try/finally block. The commit in this PR updates the relevant places to use a try-with-resources. Additionally, in the extract() implementation of the `Main` class, we use the `ZipFile` when a JAR file is being extracted. This matches with what we do in the rest of the code in that `Main` class where a jar tool operation is a being run against a file.
> 
> No new test has been added given the nature of this change and existing tests in `test/jdk/tools/jar` continue to pass with this change. tier1, tier2 and tier3 testing is currently in progress.

This pull request has now been integrated.

Changeset: 8fce5275
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fce5275fc94ebc404a6a37f5ea0407140de63c1
Stats:     181 lines in 1 file changed: 32 ins; 53 del; 96 mod

8339810: Clean up the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/20928

From djelinski at openjdk.org  Wed Sep 11 06:03:08 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 06:03:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
Message-ID: <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>

On Tue, 10 Sep 2024 21:42:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed.
>
> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`?

Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1753167982

From alanb at openjdk.org  Wed Sep 11 06:05:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Sep 2024 06:05:04 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v2]
In-Reply-To: <8VTdtkMX4R3x61e7MD36nnvnxpo_RR8-jg7J71KWLyQ=.a003d4a9-12c4-49dd-aaad-e467f5ba2003@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
 <8VTdtkMX4R3x61e7MD36nnvnxpo_RR8-jg7J71KWLyQ=.a003d4a9-12c4-49dd-aaad-e467f5ba2003@github.com>
Message-ID: <jhw7wozgtSbpO4GCNtzEdRWP_HN_I-qAF3oviMTJcI8=.e860879f-2650-482f-87b6-ec717d4bfc6b@github.com>

On Wed, 11 Sep 2024 02:28:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> With regards to the nsk tests, are `beforeSleep` and `afterSleep` still potential candidates now that it is impossible for them to throw OOME?

These tests are sampling and checking for specific methods and call stacks, I don't think they are provoke OOME. So the changes just are cleanup as these it won't sample frames with these methods with the code change. I don't think ThreadSleepEvent.<clinit> will be sampled now but maybe ThreadSleepEvent.<init> will.

These tests are crying out to be replaced as they make too hard to do changes in this area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2342693403

From dholmes at openjdk.org  Wed Sep 11 06:21:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Sep 2024 06:21:07 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v2]
In-Reply-To: <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
Message-ID: <Xz6wwCihFKkg0aU5_ZUx2FU2QFIzWSXmxD-aqPeHBWM=.aea6fadd-bee6-40d1-a337-93b10c1cb92e@github.com>

On Tue, 10 Sep 2024 21:01:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing ThreadSleepEvent from stack trace checks

If these are just methods that might be seen in a stackdump then we still need `ThreadSleepEvent.isEnabled` and `ThreadSleepEvent.<init>`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2342715153

From liach at openjdk.org  Wed Sep 11 06:44:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Sep 2024 06:44:08 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v6]
In-Reply-To: <GyLlV8FR8fcBpsQBOzL6BmFsWJowFUAspSVregDDi24=.21e4a94e-4a5b-4b8e-b69c-5f5a58baf6ff@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>
 <GyLlV8FR8fcBpsQBOzL6BmFsWJowFUAspSVregDDi24=.21e4a94e-4a5b-4b8e-b69c-5f5a58baf6ff@github.com>
Message-ID: <_zR3qTD2YcepqDBachdeb39dMvdqXZROLVqZ7nZYxEo=.5ec276f5-ffaf-46fb-8bae-6db7482edb6b@github.com>

On Wed, 11 Sep 2024 03:20:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - omission in tests
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Rename constants at new locations, link to related factories, cp tag constant names
>>  - Fix compile errors
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Compile errors; now tests are all green.
>>  - Move Constant Pool tags to PoolEntry
>>    
>>    Two unexpected usages in jlink raw processing, but rest is fine
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6fd043f1...fa9ea36d
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationBytecodes.java line 92:
> 
>> 90:             case ClassFile.WIDE:
>> 91:             case ClassFile.TABLESWITCH:
>> 92:             case ClassFile.LOOKUPSWITCH:
> 
> This?method was?removed in?[JDK?8339576] ([GH?20863]):
> Suggestion:
> 
> 
> 
> [JDK?8339576]: https://bugs.openjdk.org/browse/JDK-8339576
> [GH?20863]: https://github.com/openjdk/jdk/pull/20863

hmm, seems i forgot to push the local fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1753244260

From alanb at openjdk.org  Wed Sep 11 07:03:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Sep 2024 07:03:06 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v2]
In-Reply-To: <Xz6wwCihFKkg0aU5_ZUx2FU2QFIzWSXmxD-aqPeHBWM=.aea6fadd-bee6-40d1-a337-93b10c1cb92e@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
 <Xz6wwCihFKkg0aU5_ZUx2FU2QFIzWSXmxD-aqPeHBWM=.aea6fadd-bee6-40d1-a337-93b10c1cb92e@github.com>
Message-ID: <qXYsHgqFB8S8h2EFXF7lQKCCjXfJSVvCrpGdFen5_vc=.b86d8121-a2ae-433d-bf80-3092b6571850@github.com>

On Wed, 11 Sep 2024 06:18:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If these are just methods that might be seen in a stackdump then we still need `ThreadSleepEvent.isEnabled` and `ThreadSleepEvent.<init>`.

I think minimal here is to just drop isTurnedOn from lists in these tests. From what I can tell, the tests are sampling in a loop and can tolerate up to a limit. Hopefully someone will step up some day and replace them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2342818919

From jeisl at openjdk.org  Wed Sep 11 07:05:17 2024
From: jeisl at openjdk.org (Josef Eisl)
Date: Wed, 11 Sep 2024 07:05:17 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <DckGzEtnesPu5oN7E7KzLczbKhpQqaJGX0vQvtTSwHg=.0c3031b8-4738-4321-9295-5ac17f30de23@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com>
 <DckGzEtnesPu5oN7E7KzLczbKhpQqaJGX0vQvtTSwHg=.0c3031b8-4738-4321-9295-5ac17f30de23@github.com>
Message-ID: <lESRWyy2WhxHRFRx1AOiV3qKNxNHZ3ojcguX1oYUGg0=.275c101c-c9a3-4196-ae56-36467bc1c85c@github.com>

On Tue, 10 Sep 2024 21:47:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> sort out the mess that is libawt_headless/libawt_xawt

sounds good. can you point me to a JBS?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1753307449

From eirbjo at openjdk.org  Wed Sep 11 07:13:20 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 07:13:20 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v2]
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <DT1Cnzdf1E_BLJHRGWZs6auRSWUkPu3mgbzG0bqfEGY=.7365cb0a-d7d3-4779-a6ff-d5816694389b@github.com>

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:

 - Make UTF8ZipCoder.hasTrailingSlash private and remove the unused ZipCoder.hasTrailingSlash with the associated slashBytes() method and slashBytes field
 - Revert signature change in ZipFile.getZipEntry so iterators won't need to wrap arguments in as EntryPos instances
 - Revert change in access modifier for ZipCoder.checkedHash

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20939/files
  - new: https://git.openjdk.org/jdk/pull/20939/files/6c9f09b4..679ee585

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=00-01

  Stats: 33 lines in 2 files changed: 0 ins; 27 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20939/head:pull/20939

PR: https://git.openjdk.org/jdk/pull/20939

From eirbjo at openjdk.org  Wed Sep 11 07:16:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 07:16:40 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v3]
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <WD0HfVHKHSkP5IGByVWIJ5wshE53xvKlRwdEKKjHTPc=.377fba1b-2477-42a2-9717-a7ecafb6e2ba@github.com>

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Revert some field read ordering changes to make the PR easier to review. Move nlen read to the common path.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20939/files
  - new: https://git.openjdk.org/jdk/pull/20939/files/679ee585..b6de843b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20939/head:pull/20939

PR: https://git.openjdk.org/jdk/pull/20939

From eirbjo at openjdk.org  Wed Sep 11 07:23:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 07:23:40 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <4_sHl1cRMotj4Jt3apf_jn9QOvtdATLpRV5r2M8Vzt0=.03a66b24-44cc-422d-b09b-c0761d903eea@github.com>

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Add whitespace per review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20939/files
  - new: https://git.openjdk.org/jdk/pull/20939/files/b6de843b..f24b833a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20939/head:pull/20939

PR: https://git.openjdk.org/jdk/pull/20939

From eirbjo at openjdk.org  Wed Sep 11 07:23:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 07:23:40 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <4zLGcbWIwaZme7djDq4vYOsVzo182WHidSXdzFBIOE8=.2eae5ac4-b7a3-49a2-8c6d-78f647a2609f@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <4zLGcbWIwaZme7djDq4vYOsVzo182WHidSXdzFBIOE8=.2eae5ac4-b7a3-49a2-8c6d-78f647a2609f@github.com>
Message-ID: <6Z6IxAkzaVTYlnxDVnXo7gKCLzj220Z1ZXFru4oMyI8=.ba106a9f-f034-400a-9ec8-fd980014f194@github.com>

On Tue, 10 Sep 2024 19:30:52 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> If this does not make a huge performance difference, I would keep this together with the init of elen and clen on line 692.

I verified this does not cause a regression, so moved the `nlen` read up on the common path.

See also my comment to @cl4es re sequential memory access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753365711

From eirbjo at openjdk.org  Wed Sep 11 07:23:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 07:23:40 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <Nh-QxUwrAVb4rzOhFWxnCsXP8bDzjgJlbOVrF1Rpz2A=.c299f5a2-2fd0-4ad8-bd1d-c7807d35e8b1@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <Nh-QxUwrAVb4rzOhFWxnCsXP8bDzjgJlbOVrF1Rpz2A=.c299f5a2-2fd0-4ad8-bd1d-c7807d35e8b1@github.com>
Message-ID: <n0CE4KagCTsZ6_jlJqt5h2gyMnYiVJFWEydLnFZBNEE=.f0a2b27f-e5a4-4363-9fe7-0e57f82506e8@github.com>

On Tue, 10 Sep 2024 19:34:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add whitespace per review feedback
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 161:
> 
>> 159:     }
>> 160: 
>> 161:     protected boolean hasTrailingSlash(byte[] a, int end) {
> 
> Why are you making these `protected`? `ZipCoder` is package-private so any inheritors must be in the same package, which means they already have access to package-private methods.

Since `hasTrailingSlash` is now only used from UTFCoder and subclasses, I thought we could stricten the access to protected. But as I learned, `protected` is still accessible from the same package.

On closer inspection though, `hasTrailingSlash` is now only used from UTF8ZipEncoder.compare. So we can actually make that implementation `private` and remove the now-unused implementation from the base class, along with the `slashBytes` logic. I have pushed these changes.

What do you think?

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1891:
> 
>> 1889:             // Return the position of "name/" if we found it
>> 1890:             if (dirPos != -1) {
>> 1891:                 return new EntryPos(name +"/", dirPos);
> 
> Suggestion:
> 
>                 return new EntryPos(name + "/", dirPos);

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753356858
PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753359793

From eirbjo at openjdk.org  Wed Sep 11 07:28:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 07:28:06 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <T7nYrUW9P-eqxCauGRlSBLXjhK-qYoXaMFXeKGAElBs=.3cbed6af-92e3-4e5f-89a3-263a622a1f56@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <T7nYrUW9P-eqxCauGRlSBLXjhK-qYoXaMFXeKGAElBs=.3cbed6af-92e3-4e5f-89a3-263a622a1f56@github.com>
Message-ID: <Oq0UWwxq1ERbZba9z-duWoL0XwprXoR-G7EwWVfBGFA=.73b5315c-a244-4dad-8bec-d8301f717f07@github.com>

On Tue, 10 Sep 2024 19:57:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add whitespace per review feedback
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 549:
> 
>> 547:                 // each "entry" has 3 ints in table entries
>> 548:                 int pos = res.zsrc.getEntryPos(i++ * 3);
>> 549:                 return (T)getZipEntry(new EntryPos(getEntryName(pos), pos));
> 
> Do we have benchmarks covering the various types of iteration?

I realized it's better to keep the signature of `getZipEntry` so these iteration callers won't need to construct the EntryPos. I assume calling `getEntryName` should have similar performance characteristic to the existing code which calls `getEntryPos` with a null name, since we're just seem to be moving the String decoding from one method to another.

But no, I don't think we have benchmarks for ZipEntry enumeration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753380817

From eirbjo at openjdk.org  Wed Sep 11 08:39:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 08:39:06 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <4zLGcbWIwaZme7djDq4vYOsVzo182WHidSXdzFBIOE8=.2eae5ac4-b7a3-49a2-8c6d-78f647a2609f@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <4zLGcbWIwaZme7djDq4vYOsVzo182WHidSXdzFBIOE8=.2eae5ac4-b7a3-49a2-8c6d-78f647a2609f@github.com>
Message-ID: <jlwXoSbO3LYNfQNos5M0m5R2Rxl1YMaQiFTCXJ7nnMA=.35ed8719-e2df-4fcf-8d19-109d9811c400@github.com>

On Tue, 10 Sep 2024 19:39:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add whitespace per review feedback
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 161:
> 
>> 159:     }
>> 160: 
>> 161:     protected boolean hasTrailingSlash(byte[] a, int end) {
> 
> Can you explain the need for this

See other comment to Claes: Since UTF8ZipCoder.compare is now the only caller of this method, it can be made private.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753611453

From eirbjo at openjdk.org  Wed Sep 11 08:39:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Sep 2024 08:39:08 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <Ma6bgDDava6XplyLhKbr5QAWdrMqlU08KR8_sCebisg=.ed8971a7-e59c-492a-b9f8-554adcc3e3e9@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <Ma6bgDDava6XplyLhKbr5QAWdrMqlU08KR8_sCebisg=.ed8971a7-e59c-492a-b9f8-554adcc3e3e9@github.com>
Message-ID: <8H3ses-oSiHNMZz4szB8Dl5KtCtJxK7WbaF6SXsI3fc=.3d6010e0-1c80-44d2-896f-7e15efb74ae7@github.com>

On Tue, 10 Sep 2024 19:39:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add whitespace per review feedback
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 681:
> 
>> 679: 
>> 680:         e.flag = CENFLG(cen, pos);
>> 681:         e.method = CENHOW(cen, pos);
> 
> Not reading `nlen` when it's not needed is a good change, and moving `clen` and `elen` down to be grouped with the others is fine, but some of the other shuffling around here doesn't seem motivated?

The reordering of field reads was motivated by some previous experiences where ordering the reads sequentially with their appearance in the CEN a had small, but positive performance gain. 

After closer invetigation, it turns out that the internal ordering of field reads only has small benefits, maybe in the noise. However, reading the length fields _before the allocation of the `ZipEntry`_ has a significant negative impact. In fact, it seems to explain most of the performance gains in this PR.

It seems that having `ZipEntry` allocation interspersed within the CEN field reads incurs a significant cost. I can't explain why, but perhaps @cl4es can?  (To reproduce, simply move the length reads to the beginning of the method)

I have kept the reordering of `nlen`, `elen`, `clen` reads, but reverted some other reorderings to make the PR cleaner. 

This PR:


Benchmark                    (size)  Mode  Cnt   Score   Error  Units
ZipFileGetEntry.getEntryHit     512  avgt   15  52.057 ? 2.021  ns/op
ZipFileGetEntry.getEntryHit    1024  avgt   15  54.753 ? 1.093  ns/op


Reads length fields before `ZipEntry` allocation:


Benchmark                    (size)  Mode  Cnt   Score   Error  Units
ZipFileGetEntry.getEntryHit     512  avgt   15  65.199 ? 0.823  ns/op
ZipFileGetEntry.getEntryHit    1024  avgt   15  69.407 ? 0.807  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753604647

From kevinw at openjdk.org  Wed Sep 11 08:51:17 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Sep 2024 08:51:17 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
Message-ID: <tzwuAXVnDvgziQxJHpZPuxd0oCsGXIO1kb8M4vRUttg=.17d6d31d-8532-4615-9e1b-958bee18e75c@github.com>

On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
>> 
>> 
>> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
>> 
>> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
>> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
>> 3. Some parts of the code are written in C others in C++.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix missing code

OK thanks, so the change only affects SYSTEM accounts, and such accounts already see a different temp path to non-SYSTEM accounts.

Newer and older Java versions run by a SYSTEM account will have different temp paths, therefore the hsperfdata_username will be in a different place.

(I was being picky about attach, but it's a universal thing which is expected to work across different Java versions.)

Do we have any apps commonly run as a Windows SYSTEM account which expect to attach to other Java apps run by a different Java version?  You're suggesting that will have no impact and agreed it would seem really unusual. 8-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2343034670

From aivanov at openjdk.org  Wed Sep 11 09:10:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Sep 2024 09:10:12 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
Message-ID: <D8eCKs-aPhKABEBkipCVp3R9_1-rYJvQDTAt4nUov2U=.33e32331-3e44-4aed-8b27-d5c78d160d2d@github.com>

On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageToolTest too

Looks good to me.

It could be good to remove `@author` tags from all the modified tests.

test/jdk/java/beans/Introspector/Test5102804.java line 28:

> 26:  * @bug 5102804
> 27:  * @summary Tests memory leak
> 28:  * @author Sergey Malenkov

Could you also remove the `@author` tag?

test/jdk/java/beans/Introspector/Test8027905.java line 30:

> 28:  * @bug 8027905
> 29:  * @summary Tests that GC does not affect a property type
> 30:  * @author Sergey Malenkov

Could you also remove the `@author` tag?

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2296140348
PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753703304
PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753707545

From jpai at openjdk.org  Wed Sep 11 09:19:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 09:19:21 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
Message-ID: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>

> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
> 
> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alexey's suggestion - remove @author tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20930/files
  - new: https://git.openjdk.org/jdk/pull/20930/files/8214fdb5..1596c34c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=01-02

  Stats: 5 lines in 4 files changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20930/head:pull/20930

PR: https://git.openjdk.org/jdk/pull/20930

From jpai at openjdk.org  Wed Sep 11 09:19:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 09:19:21 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <D8eCKs-aPhKABEBkipCVp3R9_1-rYJvQDTAt4nUov2U=.33e32331-3e44-4aed-8b27-d5c78d160d2d@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
 <D8eCKs-aPhKABEBkipCVp3R9_1-rYJvQDTAt4nUov2U=.33e32331-3e44-4aed-8b27-d5c78d160d2d@github.com>
Message-ID: <9qOt-WPO0yYRk9G1dd8W2B3i_dIpNdNpoXl7PNb1Jrk=.e1b334d5-3bfa-4549-8dbc-78abf93f17ab@github.com>

On Wed, 11 Sep 2024 09:03:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update JImageToolTest too
>
> test/jdk/java/beans/Introspector/Test5102804.java line 28:
> 
>> 26:  * @bug 5102804
>> 27:  * @summary Tests memory leak
>> 28:  * @author Sergey Malenkov
> 
> Could you also remove the `@author` tag?

Done - I've now updated the PR to remove these author tags. Tests continue to pass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753742813

From aivanov at openjdk.org  Wed Sep 11 09:31:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Sep 2024 09:31:07 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <eXLvVTzpi-3Qvs9p38KECFBAYzggTKe0UoDzhp-ASSA=.3ea127f1-f2b9-443d-a893-91e1b3d48fdd@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2296196596

From dfuchs at openjdk.org  Wed Sep 11 09:48:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Sep 2024 09:48:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v6]
In-Reply-To: <J7xHiuKN0VuuPDsHOgzH-z-rHf0dm3wGareMmqVDbvo=.72be079d-b838-4286-b44e-f3baa5bff34f@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <J7xHiuKN0VuuPDsHOgzH-z-rHf0dm3wGareMmqVDbvo=.72be079d-b838-4286-b44e-f3baa5bff34f@github.com>
Message-ID: <T9FAunX7r41pmPdZ-U6-nRjYRRUpu9JBlq5FkB7IAsE=.c84abe54-f2d3-4868-82ac-4da03ae1eb23@github.com>

On Tue, 10 Sep 2024 18:41:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
>  - remove redundant clamp from timeoutLeft calculation
>  - clamp timeout and retries property values

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java line 185:

> 183:             int val = Integer.parseInt((String) propVal);
> 184:             if (retries != val) {
> 185:                 retries = Math.clamp(val, 1, 31);

Maybe we should rather use 30 here, since `1 << 1` is 2 and `1 << 31` is negative

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java line 264:

> 262:         retries = (val == null)
> 263:             ? DEFAULT_RETRIES
> 264:             : Math.clamp(Integer.parseInt(val), 1, 31);

same remark herre

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1753832166
PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1753833767

From jpai at openjdk.org  Wed Sep 11 09:52:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 09:52:38 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture -checksource
 -cs -noasyncgc options from the launcher
Message-ID: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>

Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?

As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.

tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.

Would this change require a CSR?

-------------

Commit messages:
 - Remove checks for outdated -t -tm -Xfuture -checksource -cs -noasyncgc options from the launcher

Changes: https://git.openjdk.org/jdk/pull/20945/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339918
  Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From redestad at openjdk.org  Wed Sep 11 10:05:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Sep 2024 10:05:09 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v4]
In-Reply-To: <8H3ses-oSiHNMZz4szB8Dl5KtCtJxK7WbaF6SXsI3fc=.3d6010e0-1c80-44d2-896f-7e15efb74ae7@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <Ma6bgDDava6XplyLhKbr5QAWdrMqlU08KR8_sCebisg=.ed8971a7-e59c-492a-b9f8-554adcc3e3e9@github.com>
 <8H3ses-oSiHNMZz4szB8Dl5KtCtJxK7WbaF6SXsI3fc=.3d6010e0-1c80-44d2-896f-7e15efb74ae7@github.com>
Message-ID: <-XWgVZXZnb3mITqR98CkRSjvvcjtXFQumO9OyZJl8jo=.cd4a4fff-3110-407c-a6c7-7521e1363160@github.com>

On Wed, 11 Sep 2024 08:34:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 681:
>> 
>>> 679: 
>>> 680:         e.flag = CENFLG(cen, pos);
>>> 681:         e.method = CENHOW(cen, pos);
>> 
>> Not reading `nlen` when it's not needed is a good change, and moving `clen` and `elen` down to be grouped with the others is fine, but some of the other shuffling around here doesn't seem motivated?
>
> The reordering of field reads was motivated by some previous experiences where ordering the reads sequentially with their appearance in the CEN a had small, but positive performance gain. 
> 
> After closer investigation, it turns out that the internal ordering of field reads only has small benefits, maybe in the noise. However, reading the length fields _before the allocation of the `ZipEntry`_ has a significant negative impact. In fact, it seems to explain most of the performance gains in this PR.
> 
> It seems that having `ZipEntry` allocation interspersed within the CEN field reads incurs a significant cost. I can't explain why, but perhaps @cl4es can?  (To reproduce, simply move the length reads to the beginning of the method)
> 
> I have kept the reordering of `nlen`, `elen`, `clen` reads, but reverted some other reorderings to make the PR cleaner. 
> 
> This PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.057 ? 2.021  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  54.753 ? 1.093  ns/op
> 
> 
> Reads length fields before `ZipEntry` allocation:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  65.199 ? 0.823  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  69.407 ? 0.807  ns/op

Just a guess but perhaps this is down to a cache effect where the `ZipEntry` allocation has a chance to evict the cen data array from some cache. Batching all the reads from CEN together could counter-act some such effects and better streamline memory accesses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20939#discussion_r1753891457

From alanb at openjdk.org  Wed Sep 11 10:39:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Sep 2024 10:39:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <tnjGnFeHzP8GKv3i-Op2OtZVn499CIpgJvdA3cTYbOs=.520a8e2d-bcd1-4b0f-9e0a-7bb0bbc705c3@github.com>

On Wed, 11 Sep 2024 09:47:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Would this change require a CSR?

and probably a release note too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20945#issuecomment-2343274428

From mcimadamore at openjdk.org  Wed Sep 11 11:21:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Sep 2024 11:21:15 GMT
Subject: Integrated: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than
 10 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <7RjB5Ch6MRlUYvHgnbBM4no5grO25j8oYgpIr3OP4pk=.56d50bdb-3769-4239-ae08-4f45ba35bb66@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

This pull request has now been integrated.

Changeset: 59778885
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/597788850042e7272a23714c05ba546ee6080856
Stats:     130 lines in 7 files changed: 73 ins; 31 del; 26 mod

8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames
8339780: TestByteBuffer fails on AIX after 8339285

Reviewed-by: alanb, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/20914

From jpai at openjdk.org  Wed Sep 11 11:30:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 11:30:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <PJztmQbehmGBoLG2oDlNDgQMHCcDXHVzoFIna27a228=.0740ed55-5d41-4593-80b1-3cce7668a3aa@github.com>

On Wed, 11 Sep 2024 09:47:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

The CSR for this change is now ready for review at https://bugs.openjdk.org/browse/JDK-8339928

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20945#issuecomment-2343371236

From vklang at openjdk.org  Wed Sep 11 11:42:19 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 11 Sep 2024 11:42:19 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v3]
In-Reply-To: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
Message-ID: <2WUJ5P6eH0AB8uInKj7rJd1kaDM3TazLzcl1NlqmYR4=.d6203623-9ca3-4ccf-9608-61ee7f468380@github.com>

> This PR applies @AlanBateman's patch from the JBS issue.

Viktor Klang 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 one new commit since the last revision:

  Removing ThreadSleepEvent.isTurnedOn from stack trace checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20923/files
  - new: https://git.openjdk.org/jdk/pull/20923/files/b4241e3e..92d09f8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20923&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20923&range=01-02

  Stats: 8 lines in 3 files changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20923/head:pull/20923

PR: https://git.openjdk.org/jdk/pull/20923

From vklang at openjdk.org  Wed Sep 11 11:42:19 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 11 Sep 2024 11:42:19 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v2]
In-Reply-To: <qXYsHgqFB8S8h2EFXF7lQKCCjXfJSVvCrpGdFen5_vc=.b86d8121-a2ae-433d-bf80-3092b6571850@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <JXKPqE9kFRIzkre8gYzuVO_5UhlTO9IP5NtlTkk5TTc=.5b1d1c62-c3aa-40b5-b7ea-cf2b788edfa2@github.com>
 <Xz6wwCihFKkg0aU5_ZUx2FU2QFIzWSXmxD-aqPeHBWM=.aea6fadd-bee6-40d1-a337-93b10c1cb92e@github.com>
 <qXYsHgqFB8S8h2EFXF7lQKCCjXfJSVvCrpGdFen5_vc=.b86d8121-a2ae-433d-bf80-3092b6571850@github.com>
Message-ID: <qHPWtr4RbsgrNTgDVsASo7X2phSMVWv3VWNP3nW1vcA=.00a3bdfd-ac87-474b-90c1-4ead014f87ca@github.com>

On Wed, 11 Sep 2024 07:00:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If these are just methods that might be seen in a stackdump then we still need `ThreadSleepEvent.isEnabled` and `ThreadSleepEvent.<init>`.
>
>> If these are just methods that might be seen in a stackdump then we still need `ThreadSleepEvent.isEnabled` and `ThreadSleepEvent.<init>`.
> 
> I think minimal here is to just drop isTurnedOn from lists in these tests. From what I can tell, the tests are sampling in a loop and can tolerate up to a limit. Hopefully someone will step up some day and replace them.

@AlanBateman @dholmes-ora Ok, that's fair enough. I have replaced the commit which dropped all three in the trace to just dropping the isTurnedOn frame.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2343431165

From rgiulietti at openjdk.org  Wed Sep 11 11:53:12 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Sep 2024 11:53:12 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
Message-ID: <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>

On Sat, 7 Sep 2024 20:39:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
>  - Removed redundant code

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 43:

> 41:  * @build java.base/java.math.MutableBigIntegerBox
> 42:  * @key randomness
> 43:  * @run junit/othervm -DmaxDurationMillis=3000 MutableBigIntegerShiftTests

There's no need to have a max duration here, as there's no great risk of CPU consumption.

Suggestion:

 * @run junit MutableBigIntegerShiftTests

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 47:

> 45: public class MutableBigIntegerShiftTests {
> 46: 
> 47:     private static final int DEFAULT_MAX_DURATION_MILLIS = 3_000;

Remove

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 52:

> 50:     static final int ORDER_MEDIUM = 100;
> 51: 
> 52:     private static int maxDurationMillis;

Remove

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 53:

> 51: 
> 52:     private static int maxDurationMillis;
> 53:     private static Random random = RandomFactory.getRandom();

Suggestion:

    private static final Random random = RandomFactory.getRandom();

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 55:

> 53:     private static Random random = RandomFactory.getRandom();
> 54: 
> 55:     static boolean failure = false;

Remove

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 60:

> 58:     static void setMaxDurationMillis() {
> 59:         maxDurationMillis = Math.max(maxDurationMillis(), 0);
> 60:     }

Remove

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 65:

> 63:         for (int i = 0; i < 100; i++) {
> 64:             MutableBigIntegerBox x = fetchNumber(order);
> 65:             int n = Math.abs(random.nextInt() % 200);

Suggestion:

            int n = random.nextInt(200);

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 67:

> 65:             int n = Math.abs(random.nextInt() % 200);
> 66: 
> 67:             assertTrue(x.shiftLeft(n).compare

Better to use `assertEquals()`: better messages in case of failure, with an "expected" and an "actual" value.

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 71:

> 69:                     "Inconsistent left shift: " + x + "<<" + n + " != " + x + "*2^" + n);
> 70: 
> 71:             assertTrue(x.shiftLeft(n).shiftRight(n).compare(x) == 0,

Same

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 77:

> 75: 
> 76:     @Test
> 77:     public static void testShift() {

A JUnit test should be non-static.

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 79:

> 77:     public static void testShift() {
> 78:         shift(ORDER_SMALL);
> 79:         shift(ORDER_MEDIUM);

JUnit has parameterized tests, which help to identify the parameter value in case of failure.

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 107:

> 105:                 int numInts = (order + 31) >> 5;
> 106:                 int[] fullBits = new int[numInts];
> 107:                 for(int i = 0; i < numInts; i++)

`Arrays.fill()`?

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 153:

> 151: 
> 152:         return result;
> 153:     }

I think this is getting too complex for a test, there's a risk that it is incorrect...

Is there perhaps a way to have simpler code?

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 163:

> 161:         return DEFAULT_MAX_DURATION_MILLIS;
> 162:     }
> 163: }

Remove

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754212513
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754214453
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754214570
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754222080
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754214679
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754214930
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754215136
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754215802
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754215995
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754216164
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754216332
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754216672
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754216920
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754217053

From alanb at openjdk.org  Wed Sep 11 11:55:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Sep 2024 11:55:06 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v3]
In-Reply-To: <2WUJ5P6eH0AB8uInKj7rJd1kaDM3TazLzcl1NlqmYR4=.d6203623-9ca3-4ccf-9608-61ee7f468380@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <2WUJ5P6eH0AB8uInKj7rJd1kaDM3TazLzcl1NlqmYR4=.d6203623-9ca3-4ccf-9608-61ee7f468380@github.com>
Message-ID: <pQ9Lg0vGPLnuv61muPbvujWmFy8lAS6jfZeoqCRijY0=.4572afc1-c509-458a-a5a1-75fbedc55e94@github.com>

On Wed, 11 Sep 2024 11:42:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang 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 one new commit since the last revision:
> 
>   Removing ThreadSleepEvent.isTurnedOn from stack trace checks

Thanks for taking this one.

These ancient nsk tests are annoying, removing isTurnedOn from the list of methods that can be sampled in frames seems fine. Hopefully someone will take pity and these tests and replace them.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20923#pullrequestreview-2296642402

From duke at openjdk.org  Wed Sep 11 12:48:07 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 11 Sep 2024 12:48:07 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
 <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
Message-ID: <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>

On Wed, 11 Sep 2024 11:48:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
>>  - Removed redundant code
>
> test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 153:
> 
>> 151: 
>> 152:         return result;
>> 153:     }
> 
> I think this is getting too complex for a test, there's a risk that it is incorrect...
> 
> Is there perhaps a way to have simpler code?

The test cases of the code are the same of the test class for `BigInteger.shiftLeft()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754390582

From rgiulietti at openjdk.org  Wed Sep 11 12:51:33 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Sep 2024 12:51:33 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method
Message-ID: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>

`Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.

-------------

Commit messages:
 - 8339934: Simplify Math.scalb(double) method

Changes: https://git.openjdk.org/jdk/pull/20948/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20948&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339934
  Stats: 57 lines in 1 file changed: 6 ins; 35 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20948/head:pull/20948

PR: https://git.openjdk.org/jdk/pull/20948

From rgiulietti at openjdk.org  Wed Sep 11 12:51:33 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Sep 2024 12:51:33 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method
In-Reply-To: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
Message-ID: <Opg1k0EgSm_2cFBFhnJo8a7I8IydhB_tBL42FOXqtGU=.7278b367-623b-43f1-9cb5-43e6c6cc9c2a@github.com>

On Wed, 11 Sep 2024 12:45:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> `Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.

The proposed implementation is even about 1.5x faster, but that's not the point of this PR.
The point is to have simpler logic.
Similar logic could be adopted for the `float` case as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20948#issuecomment-2343578028

From pminborg at openjdk.org  Wed Sep 11 13:13:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Sep 2024 13:13:07 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <k9YKNmPqzfp9CuOWgvklilmTVVv6ibBUXU3Jj1BwEOQ=.5f30c9ed-3aa5-46ad-83a9-3e0cfc248aee@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
 <k9YKNmPqzfp9CuOWgvklilmTVVv6ibBUXU3Jj1BwEOQ=.5f30c9ed-3aa5-46ad-83a9-3e0cfc248aee@github.com>
Message-ID: <Pqno2HyVuYibmcYjdO--ys3rjM3bWtAnJ4o1602hUhA=.65e9744a-5269-43bb-a774-ac78a076d558@github.com>

On Thu, 5 Sep 2024 17:51:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix errors in a benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 175:
> 
>> 173:         } else {
>> 174:             long i;
>> 175:             if (SCOPED_MEMORY_ACCESS.getByte(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset) !=
> 
> I looked at this the other day, and I couldn't immediately tell whether this test is needed or not - shouldn't it be covered by the subsequent loop? Is it a shortcut (but only for the first element) - how much does that buy really?

I think this is an escape hatch that may trigger for random contents. Depending on the use case, this may or may not pay off. Maybe we should define an input distribution for which performance should be tuned against.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1754477120

From pminborg at openjdk.org  Wed Sep 11 13:18:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Sep 2024 13:18:06 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <AYbLj-T19q6gIcFEisoGFkkbQlpJ3Lzm-LjXwazsSE0=.61cdf34f-0c59-408b-bb2d-1150997d7e5d@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
 <AYbLj-T19q6gIcFEisoGFkkbQlpJ3Lzm-LjXwazsSE0=.61cdf34f-0c59-408b-bb2d-1150997d7e5d@github.com>
Message-ID: <L_eysRv6ew-6Vp6IPqXUhQXlKrUgr88w5Qlk_nl9Nss=.1a388afc-75cf-4579-bdf7-73c16f9f8b2c@github.com>

On Fri, 6 Sep 2024 15:11:19 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix errors in a benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 244:
> 
>> 242:         return (Architecture.isLittleEndian()
>> 243:                 ? Long.numberOfTrailingZeros(x)
>> 244:                 : Long.numberOfLeadingZeros(x)) / 8;
> 
> Would there be value in having a constant LongToIntFunction lambda to capture this logic?
> 
> 
> private static final LongToIntFunction LONG_LEADING_ZEROS = Architecture.isLittleEndian() ? Long::numberOfTrailingZeros : Long::numberOfLeadingZeros;

Performance-wise, I suspect there would not be that much of a difference. The compiler will see that Architecture.isLittleEndian provides a stable value and can optimize and eliminate code (I think). I am unsure which is easier to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1754496696

From pminborg at openjdk.org  Wed Sep 11 13:23:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Sep 2024 13:23:07 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <Y0YYrjRsgqImAAGTQcTRvIov-GM7MGhpePAsujcNAN8=.db2d6c56-1a8a-45e1-8d33-0021eee11fa6@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
 <Y0YYrjRsgqImAAGTQcTRvIov-GM7MGhpePAsujcNAN8=.db2d6c56-1a8a-45e1-8d33-0021eee11fa6@github.com>
Message-ID: <9j1QRaKnmT-e1ScAlkXiVgkLzhbfedqv1yS1uAlvYw4=.d0dddf03-7595-44f3-a84b-61025192956b@github.com>

On Thu, 5 Sep 2024 17:58:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix errors in a benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 211:
> 
>> 209:             final int s = SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(), src.unsafeGetOffset() + srcFromOffset + offset);
>> 210:             final int d = SCOPED_MEMORY_ACCESS.getInt(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + dstFromOffset + offset);
>> 211:             if (s != d) {
> 
> Can we run `mismatch(s, d)` and then check the returned index (e.g. `!= 0`) instead of doing a full comparison and then another mismatch? Or is that slower?

Assuming the most likely outcome is the values `s` and `d` are the same, I think the current way is faster. We avoid xor and counting bits which we likely do not have any use for.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1754510267

From sgehwolf at openjdk.org  Wed Sep 11 14:13:50 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 11 Sep 2024 14:13:50 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v11]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and cgroups v2 (since [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) is fixed now).
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 and cg v2 (passes).
> - [x] GHA

Severin Gehwolf 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 20 additional commits since the last revision:

 - Remove test from problem list as the bug is fixed
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Improve reliability of cpu quota test
 - Adapt JDK-8339148
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Fix comment of WB::host_cpus()
 - Handle non-root + CGv2
 - Add nested hierarchy to test framework
 - Revert "Add root check for SystemdMemoryAwarenessTest.java"
   
   This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
 - ... and 10 more: https://git.openjdk.org/jdk/compare/9fc62b11...88298b99

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19530/files
  - new: https://git.openjdk.org/jdk/pull/19530/files/0e52e004..88298b99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=09-10

  Stats: 11492 lines in 376 files changed: 6584 ins; 3192 del; 1716 mod
  Patch: https://git.openjdk.org/jdk/pull/19530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530

PR: https://git.openjdk.org/jdk/pull/19530

From duke at openjdk.org  Wed Sep 11 14:23:40 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 11 Sep 2024 14:23:40 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v8]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <H3343ngFSY0Vm0J4mK3ULirIukqdonyvZCOwlJinogg=.66fe79ae-1dba-4341-9211-3fc31ee42e22@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Revision tests changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/b48fb7a9..9504d767

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=06-07

  Stats: 58 lines in 2 files changed: 18 ins; 28 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From sgehwolf at openjdk.org  Wed Sep 11 14:28:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 11 Sep 2024 14:28:12 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v11]
In-Reply-To: <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
Message-ID: <eHYkJI6H8D8bv3E9pBlblfaxLjoJ65GRZIfOepFkw1k=.7f6939ec-3f3b-4426-8b54-62a63f3024a3@github.com>

On Wed, 11 Sep 2024 14:13:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and cgroups v2 (since [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) is fixed now).
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 and cg v2 (passes).
>> - [x] GHA
>
> Severin Gehwolf 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 20 additional commits since the last revision:
> 
>  - Remove test from problem list as the bug is fixed
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Improve reliability of cpu quota test
>  - Adapt JDK-8339148
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/4356d152...88298b99

I've merged master and removed the test from the problem list since the relevant bug got fixed.

@MBaesken Said changes require a re-review before this patch would be ready for integration. Could you please take another look? Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2343834760

From mbaesken at openjdk.org  Wed Sep 11 14:47:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Sep 2024 14:47:10 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v11]
In-Reply-To: <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
Message-ID: <8ZpNAV_DAu8VYhV-IJ6fb7fkpmCLruZIQfes8zCu3pk=.23c0bb58-b156-4bcd-8f49-3413daa6780a@github.com>

On Wed, 11 Sep 2024 14:13:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and cgroups v2 (since [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) is fixed now).
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 and cg v2 (passes).
>> - [x] GHA
>
> Severin Gehwolf 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 20 additional commits since the last revision:
> 
>  - Remove test from problem list as the bug is fixed
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Improve reliability of cpu quota test
>  - Adapt JDK-8339148
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/66848ed0...88298b99

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19530#pullrequestreview-2297384611

From zzambers at openjdk.org  Wed Sep 11 14:53:09 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Wed, 11 Sep 2024 14:53:09 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v11]
In-Reply-To: <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
Message-ID: <6_3Dyh7FDNEuXHcPa0Zr9YjMu463CLIXSVC1e5Wj5vE=.6f32dbad-2d51-426a-9d4b-2e00e6a0a9bb@github.com>

On Wed, 11 Sep 2024 14:13:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and cgroups v2 (since [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) is fixed now).
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 and cg v2 (passes).
>> - [x] GHA
>
> Severin Gehwolf 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 20 additional commits since the last revision:
> 
>  - Remove test from problem list as the bug is fixed
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Improve reliability of cpu quota test
>  - Adapt JDK-8339148
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/5447f2da...88298b99

Marked as reviewed by zzambers (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19530#pullrequestreview-2297414719

From aefimov at openjdk.org  Wed Sep 11 15:01:05 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 11 Sep 2024 15:01:05 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <Ma_5S4QCa5-k6jNnOQVg2LUXoqQCXg08d6MfNp_bC28=.19b9a405-c7fe-4225-b020-07d06aee35f4@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
 <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
 <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>
 <8gQI8QaHUU8Je6KG15-k-7IwYOw1GNQCZxkJ5UDTMVI=.ba34290b-92eb-4d60-af03-0d8c804c04e4@github.com>
 <Ma_5S4QCa5-k6jNnOQVg2LUXoqQCXg08d6MfNp_bC28=.19b9a405-c7fe-4225-b020-07d06aee35f4@github.com>
Message-ID: <Ao7H86welwCmTNthpR0PNZ-iC2tkngVn54MkCjzbDtc=.30fc0ed1-0055-4962-a624-2c3a33c4441f@github.com>

On Tue, 10 Sep 2024 19:01:54 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> I agree that we don't want to document too much here. Updated the factor to 1.75 (2 seems a bit high and might hide real issues), and to make the timeout value calculation and check less arcane - I have updated test output to print the range of acceptable timeout values: 05ed9e053865293a1938ed7bc6fe208759513813
>
> 2 time  is not too high,
> I have presented, in the comment, a failures with the elapsed time is almost twice the expected time
> where the elapsed time is 14229 !! which is approx 1.84 * expected timeout

Let me try to summarize all timeout related test failures we've observed so far:

1. Observed timeout is less than expected/calculated one by a small quantity (250 ms or less). A failure example: `Failed: timeout in 7749 ms, expected 7750ms`. The possible reason: is the 50 ms tolerance (per retry) in DNS client implementation. Possible solutions: adjust test expectations to take the 50 ms into account OR remove the 50 ms tolerance (set it to 0).

2. Observed timeout is much higher than expected/calculated one by a signigicant amount. A failure example: `Failed: timeout in 14229 ms, expected 7750ms`. The possible reason: tests are run on a busy machines. Possible solution: update the max allowed timeout to be 2x expected/calculated.

3. Observed timeout is much less than expected/calculated one by a significant amount. A failure example: `Failed: timeout in 5786 ms, expected to be in a range (ms): 7505 - 13562`. The possible reason: If there is an exception observed inside the retry loop (inside `DnsClient.query` method) the timeout left from the interrupted attempt is not carried over to the next one, therefore the difference can be as huge as a duration of one of retry attempts. Possible solution: implement the carry over of the left timeout of an interrupted attempt to the next one (or restart the interrupted retry attempt). 

I will address the 1st and the 2nd scenarios now. And will start working on the 3rd one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1754857360

From coffeys at openjdk.org  Wed Sep 11 15:16:08 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 11 Sep 2024 15:16:08 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
Message-ID: <NH3VhaW-oj56ry6n1oGn7GwPVzPFlMFhLaVO20iZ9po=.0a4edbbd-78cb-4117-91ff-d0c5290f7c38@github.com>

On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tz files aligned with the default TzdbZoneRulesProvider list

LGTM

`sun/util/calendar/zi/TestZoneInfo310.java` exercises the tzdb compiler. I wonder if it's worth adding some dummy rules which test the new leniency added to the compiler ? (perhaps even just to the jdk11_backward file included in the test dir)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2343959123

From aefimov at openjdk.org  Wed Sep 11 15:22:43 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 11 Sep 2024 15:22:43 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v7]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <-8Sgt8gh3ixnt1nlxVQ8xax_hiaY6PjlFiII5zLbTiY=.ed114679-d78d-4e21-b865-5c6f699e4fb2@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:

 - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
 -  set max allowed value for retries to 30

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/05ed9e05..bdc79d42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=05-06

  Stats: 15 lines in 4 files changed: 0 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From rgiulietti at openjdk.org  Wed Sep 11 15:37:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Sep 2024 15:37:06 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v8]
In-Reply-To: <H3343ngFSY0Vm0J4mK3ULirIukqdonyvZCOwlJinogg=.66fe79ae-1dba-4341-9211-3fc31ee42e22@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <H3343ngFSY0Vm0J4mK3ULirIukqdonyvZCOwlJinogg=.66fe79ae-1dba-4341-9211-3fc31ee42e22@github.com>
Message-ID: <QFGJS5eU50R6eBbqGVXEP-ndJlW0vyZX0C9nWlksJZM=.3c6bf379-fe47-4c47-bc39-c0fde7b572eb@github.com>

On Wed, 11 Sep 2024 14:23:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revision tests changes

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 26:

> 24: import jdk.test.lib.RandomFactory;
> 25: import org.junit.jupiter.params.ParameterizedTest;
> 26: import org.junit.jupiter.params.provider.FieldSource;

Unfortunately, the version of JUnit included in the jtreg test harness does not yet have `FieldSource` :-(
Here and below are my suggestions for an alternative.
Suggestion:

import org.junit.jupiter.params.provider.MethodSource;

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 50:

> 48:     static final int ORDER_SMALL = 60;
> 49:     static final int ORDER_MEDIUM = 100;
> 50:     static final int[] ORDERS = { ORDER_SMALL, ORDER_MEDIUM };

Suggestion:


    private static int[] orders() {
        return new int[] { ORDER_SMALL, ORDER_MEDIUM };
    }

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 55:

> 53: 
> 54:     @ParameterizedTest
> 55:     @FieldSource("ORDERS")

Suggestion:

    @MethodSource("orders")

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754980042
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754980612
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754980828

From rgiulietti at openjdk.org  Wed Sep 11 15:37:07 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Sep 2024 15:37:07 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
 <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
 <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>
Message-ID: <c0329jZF4HvMc4aHMw5Dg3OyK0S2cVyIIMJaEGrCDBw=.cbdccfa9-414b-4baf-995f-e3e6973adea7@github.com>

On Wed, 11 Sep 2024 12:44:54 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 153:
>> 
>>> 151: 
>>> 152:         return result;
>>> 153:     }
>> 
>> I think this is getting too complex for a test, there's a risk that it is incorrect...
>> 
>> Is there perhaps a way to have simpler code?
>
> The test cases of the code are the same of the test class for `BigInteger.shiftLeft()`.

I see (with obvious adaptations and one more `case`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1754982318

From duke at openjdk.org  Wed Sep 11 15:51:25 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 11 Sep 2024 15:51:25 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use supported annotation by jtreg in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/9504d767..daa2d157

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=07-08

  Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From ascarpino at openjdk.org  Wed Sep 11 16:11:09 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 11 Sep 2024 16:11:09 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <dc5D7ucI9MTKMW74YYMEW3OSd8gFQWJCpC_JHYnJER0=.c9c4f334-261b-4cdc-915c-59c6451f0bd9@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

The Cache.java change, and the others, look good to me.

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2297774755

From naoto at openjdk.org  Wed Sep 11 16:25:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Sep 2024 16:25:05 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <NH3VhaW-oj56ry6n1oGn7GwPVzPFlMFhLaVO20iZ9po=.0a4edbbd-78cb-4117-91ff-d0c5290f7c38@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
 <NH3VhaW-oj56ry6n1oGn7GwPVzPFlMFhLaVO20iZ9po=.0a4edbbd-78cb-4117-91ff-d0c5290f7c38@github.com>
Message-ID: <QCytxIUB_1R5EJSqlhtCuzLBYOEkVY89IL4Z9e6GJl4=.3ff19d95-34e0-42c5-8713-bf53c420b1ad@github.com>

On Wed, 11 Sep 2024 15:13:25 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tz files aligned with the default TzdbZoneRulesProvider list
>
> LGTM
> 
> `sun/util/calendar/zi/TestZoneInfo310.java` exercises the tzdb compiler. I wonder if it's worth adding some dummy rules which test the new leniency added to the compiler ? (perhaps even just to the jdk11_backward file included in the test dir)

Thanks, @coffeys 

> `sun/util/calendar/zi/TestZoneInfo310.java` exercises the tzdb compiler. I wonder if it's worth adding some dummy rules which test the new leniency added to the compiler ? (perhaps even just to the jdk11_backward file included in the test dir)

IIUC the purpose of that test is to check the integrity of `tzdb.dat` which is created at the JDK build time, with the pre-310 era javazic. So adding extra tz files at the test time would break (because `tzdb.dat` do not include that lenient test tz file). Testing of JDK build tool is hard IMO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2344111564

From dfuchs at openjdk.org  Wed Sep 11 16:26:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Sep 2024 16:26:06 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v7]
In-Reply-To: <-8Sgt8gh3ixnt1nlxVQ8xax_hiaY6PjlFiII5zLbTiY=.ed114679-d78d-4e21-b865-5c6f699e4fb2@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <-8Sgt8gh3ixnt1nlxVQ8xax_hiaY6PjlFiII5zLbTiY=.ed114679-d78d-4e21-b865-5c6f699e4fb2@github.com>
Message-ID: <J_EpbWDZ623hJH721R0eUyfX1v2hvjpd4vGI7NOBKDo=.f68b8085-1cd0-406f-ad2c-0cbe1092b125@github.com>

On Wed, 11 Sep 2024 15:22:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
>  -  set max allowed value for retries to 30

+1 for changing MIN_TIMEOUT to 0. I don't understand what the original intent was when the 50ms value was introduced.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2344117302

From dfuchs at openjdk.org  Wed Sep 11 16:30:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Sep 2024 16:30:10 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <Ma_5S4QCa5-k6jNnOQVg2LUXoqQCXg08d6MfNp_bC28=.19b9a405-c7fe-4225-b020-07d06aee35f4@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
 <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
 <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>
 <8gQI8QaHUU8Je6KG15-k-7IwYOw1GNQCZxkJ5UDTMVI=.ba34290b-92eb-4d60-af03-0d8c804c04e4@github.com>
 <Ma_5S4QCa5-k6jNnOQVg2LUXoqQCXg08d6MfNp_bC28=.19b9a405-c7fe-4225-b020-07d06aee35f4@github.com>
Message-ID: <94p0hdl62YchjVI6-UNZ3Vp1SFSWAHVC348whuK_f0o=.8a831b98-7046-4786-912b-870b6085575a@github.com>

On Tue, 10 Sep 2024 19:01:54 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> I agree that we don't want to document too much here. Updated the factor to 1.75 (2 seems a bit high and might hide real issues), and to make the timeout value calculation and check less arcane - I have updated test output to print the range of acceptable timeout values: 05ed9e053865293a1938ed7bc6fe208759513813
>
> 2 time  is not too high,
> I have presented, in the comment, a failures with the elapsed time is almost twice the expected time
> where the elapsed time is 14229 !! which is approx 1.84 * expected timeout

@msheppar with the latest proposed change to set MIN_TIMEOUT to 0, then I believe the `@implNote` you suggested is no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1755135496

From bpb at openjdk.org  Wed Sep 11 16:36:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 16:36:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
Message-ID: <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>

On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`?
>
> Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`.

>From a clean build in the CI with `mswsock.lib` removed:


[2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol
TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755143206

From prr at openjdk.org  Wed Sep 11 16:39:05 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Sep 2024 16:39:05 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <ubESMuJjjv36Eyku3WfS0LHwxIQy4uzrbAH0g4ZK2Po=.b029f131-1f37-4106-8c9c-ae6c335cafb6@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2297881944

From sgehwolf at openjdk.org  Wed Sep 11 16:42:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 11 Sep 2024 16:42:11 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v11]
In-Reply-To: <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <UIHFEKMXilNB5pNmuLw57LZ_QSPkkI9ET-4eCUIyFr0=.7ab9a467-dfe9-4d62-bedb-8867eee58cbc@github.com>
Message-ID: <Pc-wAUQ71YO4jpc2CoKC2AMgMu4mqvLh4V86qAyeRrk=.e29f958b-3515-461b-b8a4-8777ee9ad783@github.com>

On Wed, 11 Sep 2024 14:13:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and cgroups v2 (since [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) is fixed now).
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 and cg v2 (passes).
>> - [x] GHA
>
> Severin Gehwolf 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 20 additional commits since the last revision:
> 
>  - Remove test from problem list as the bug is fixed
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Improve reliability of cpu quota test
>  - Adapt JDK-8339148
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/18576f5a...88298b99

Thanks all for the re-reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2344148032

From djelinski at openjdk.org  Wed Sep 11 16:51:08 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 16:51:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
Message-ID: <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>

On Wed, 11 Sep 2024 16:33:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`.
>
> From a clean build in the CI with `mswsock.lib` removed:
> 
> 
> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol
> TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0

did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89).
There's no FileDispatcherImpl.obj in libnio.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755161852

From djelinski at openjdk.org  Wed Sep 11 16:54:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 16:54:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>
Message-ID: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com>

On Tue, 10 Sep 2024 19:58:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:
>> 
>>> 573:      * Used to trigger loading of native libraries
>>> 574:      */
>>> 575:     public static void load() { }
>> 
>> do we still need this method?
>
> Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions.

that's a good point. The comment might need to be updated to reflect that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755166228

From sgehwolf at openjdk.org  Wed Sep 11 17:00:17 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 11 Sep 2024 17:00:17 GMT
Subject: Integrated: 8333446: Add tests for hierarchical container support
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <oo7XqCdPLrR6oXTAndFHNXD6l9NA0Bua7cYIS_c7hbg=.57286104-8983-4de7-9e57-8a6f52359ace@github.com>

On Mon, 3 Jun 2024 17:28:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and cgroups v2 (since [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) is fixed now).
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 and cg v2 (passes).
> - [x] GHA

This pull request has now been integrated.

Changeset: d9fdf69c
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9fdf69c34c20e0f2d526c2f04450acb904c3e80
Stats:     655 lines in 9 files changed: 648 ins; 0 del; 7 mod

8333446: Add tests for hierarchical container support

Reviewed-by: mbaesken, zzambers

-------------

PR: https://git.openjdk.org/jdk/pull/19530

From sviswanathan at openjdk.org  Wed Sep 11 17:24:11 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Sep 2024 17:24:11 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
 <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
 <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
Message-ID: <Dwz8MeAFvbFh3_eUw7nKK4HcDZAAHSLg9b8qYBli0RI=.86a8c51d-4a1d-48f0-9910-16fb6ca2bb46@github.com>

On Wed, 11 Sep 2024 01:59:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> If the test is going to use randomness, then its jtreg tags should include
>>> 
>>> `@key randomness`
>>> 
>>> and it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.
>> 
>> Please see the test updated to use `@key randomness` and` jdk.test.lib.RandomFactory` to get and Random object.
>> 
>>> The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.
>>> For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).
>>>
>> So far the tests haven't failed with error of 2.5ulp. Would it be better to make it 5ulp? Please let me know.
>
> So far, this will be the only intrinsic implementation of tanh. Therefore, at the moment it is just checking the consistency of the intrinsic implementation with StrictMath/FDLIBM tanh. If the intrinsic has a ~1 ulp accuracy, it would be expected to often be within 2.5 ulps of FDLIBM tanh. However, as written the regression test would not necessarily pass against any allowable Math.tanh implementation, which is the usual criteria for java.lang.Math tests that aren't otherwise constrained (such as by being limited to a given subset of platforms).
> 
> If there was a correctly rounded tanh to compare against, then this style of testing would be valid.
> 
> Are there any plan to intrinsify sinh or cosh?

I think instead of random we should generate offline additional correctly rounded fixed test points to cater to new algorithm using high precision arithmetic library and then simply extend the HyperbolicTests.java with these new fixed test points using existing ulp testing mechanism in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1755203926

From sgehwolf at openjdk.org  Wed Sep 11 17:52:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 11 Sep 2024 17:52:44 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v8]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <UTnnI1alBcxtGobkQuwiqk5uBi1wf6So9NKkIp58GqA=.0a1a1060-dd97-4a11-86bf-705ea8169ed2@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 proposed 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 32 commits:

 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Improve systemd slice test for non-root on cg v2
 - Fix unit tests
 - Add JVM_HostActiveProcessorCount using JVM api
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - Adjust test and fix code to return lowest hierarchical limit
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - ... and 22 more: https://git.openjdk.org/jdk/compare/d9fdf69c...0f559199

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=07
  Stats: 1595 lines in 26 files changed: 1344 ins; 152 del; 99 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 duke at openjdk.org  Wed Sep 11 18:02:06 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Sep 2024 18:02:06 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <Dwz8MeAFvbFh3_eUw7nKK4HcDZAAHSLg9b8qYBli0RI=.86a8c51d-4a1d-48f0-9910-16fb6ca2bb46@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
 <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
 <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
 <Dwz8MeAFvbFh3_eUw7nKK4HcDZAAHSLg9b8qYBli0RI=.86a8c51d-4a1d-48f0-9910-16fb6ca2bb46@github.com>
Message-ID: <Q4_YgyeNlX_xOXVrbLgJQXuq3nFkQqaTcxk1y8Zgmuw=.e3b6cb0b-f621-4ce4-90ea-6890961bfe4b@github.com>

On Wed, 11 Sep 2024 17:21:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> So far, this will be the only intrinsic implementation of tanh. Therefore, at the moment it is just checking the consistency of the intrinsic implementation with StrictMath/FDLIBM tanh. If the intrinsic has a ~1 ulp accuracy, it would be expected to often be within 2.5 ulps of FDLIBM tanh. However, as written the regression test would not necessarily pass against any allowable Math.tanh implementation, which is the usual criteria for java.lang.Math tests that aren't otherwise constrained (such as by being limited to a given subset of platforms).
>> 
>> If there was a correctly rounded tanh to compare against, then this style of testing would be valid.
>> 
>> Are there any plan to intrinsify sinh or cosh?
>
> I think instead of random we should generate offline additional correctly rounded fixed test points to cater to new algorithm using high precision arithmetic library and then simply extend the HyperbolicTests.java with these new fixed test points using existing ulp testing mechanism in the test.

Thank you Sandhya(@sviswa7) for the suggestion! Will update the existing HyperbolicTests.java with new fixed point tests with quad precision reference values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1755258108

From coffeys at openjdk.org  Wed Sep 11 18:37:05 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 11 Sep 2024 18:37:05 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
Message-ID: <joASYSZ81JN0MRVXGFbC1B4Ut7DGHQT7EVQrnkoNeXA=.6f32a60b-b0b2-4b1f-bbf4-76bbb27b0ff5@github.com>

On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tz files aligned with the default TzdbZoneRulesProvider list

ah yes, it's the other way around then (java zi compiler creating legacy data to match JSR 310 data) - ok, impossible to test then..  outside of setting up a build test env.

maybe you can verify with a few simple edits to a tzdata file and building.

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20940#pullrequestreview-2298211125

From bchristi at openjdk.org  Wed Sep 11 19:05:09 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 11 Sep 2024 19:05:09 GMT
Subject: Integrated: 8339687: Rearrange reachabilityFence()s in
 jdk.test.lib.util.ForceGC
In-Reply-To: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
References: <G-YeZD1oCGBJ_oeFxMr6EUfdoijDvWvgXq77bD_G2go=.bc30fa67-00c0-4097-8288-d904ddcb7ee8@github.com>
Message-ID: <50GOTFKAiRlyV18XIujcJCHXDUMLs1BnB68EF940tgw=.eff1f7a7-f888-40d8-800a-bec928121a0f@github.com>

On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls for 'obj' and 'ref'.
> 
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set to null, so effectively does nothing. It should occur before obj = null;
> 
> For Reference.reachabilityFence(ref): 'ref' is a PhantomReference to 'obj', and is registered with 'queue'. ForceGC.waitFor() later remove()s the reference from the queue, as an indication that some GC and reference processing has taken place (hopefully causing the BooleanSupplier to return true).
> 
> The code expects the PhantomReference to be cleared and be put on the queue. But recall that a Reference refers to its queue, and not the other way around. If a Reference becomes unreachable and is garbage collected, it will never be enqueued.
> 
> I argue that the VM/GC could determine that 'ref' is not used by waitFor() and collect it before the call to queue.remove(). Moving Reference.reachabilityFence(ref) after the for() loop would prevent this scenario.
> 
> While this is only a very minor deficiency in ForceGC, I believe it would be good to ensure that the code behaves as expected.

This pull request has now been integrated.

Changeset: 51b85a1f
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51b85a1f692fed7a66bdc0fae21438a60aafe7c2
Stats:     22 lines in 1 file changed: 3 ins; 2 del; 17 mod

8339687: Rearrange reachabilityFence()s in jdk.test.lib.util.ForceGC

Reviewed-by: dholmes, smarks, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/20898

From iklam at openjdk.org  Wed Sep 11 19:09:04 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Sep 2024 19:09:04 GMT
Subject: RFR: 8338747: hasIncubatorModules needs to be generated when
 module resolution required at startup
In-Reply-To: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
References: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
Message-ID: <KaGONP0Yb1nE5CKJPsWtiNrnZElSyNsx7HLrUc52zII=.0a1e2595-6fd7-4fca-ae91-3a8a02fc50d3@github.com>

On Mon, 2 Sep 2024 12:27:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR proposes changes to the ModuleBootstrap code that is used with CDS (Ahead-of-Time Class Loading & Linking in the future). At things stand, the module graph and boot layer can be archived at dump time (-Xshare:dump) when the initial module is the class path or the initial module is in the run-time image. Future work will extend this to deployments with an application module path or where additional root modules are specified with --add-modules. To get there we need the code that determines whether to archive is in one place, and it needs to know if the module graph contains incubator modules or split packages. 
> 
> Testing: tier1-tier6. There are no new tests, the changes don't expand or change what can be archived. Calvin has done some some testing with the change as it is needed for [JDK-8328313](https://bugs.openjdk.org/browse/JDK-8328313).

I can confirm that the problem reported in the bug has been fixed. I added the following prints:


        // Step 8: CDS dump phase

+       if (CDS.isDumpingStaticArchive()) {
+           boolean hasSplitPackages = containsSplitPackages(cf);
+           boolean hasIncubatorModules = containsIncubatorModule(cf);
+           System.out.println("hasSplitPackages    = " + hasSplitPackages);
+           System.out.println("hasIncubatorModules = " + hasIncubatorModules);
+       }

        if (CDS.isDumpingStaticArchive() && !haveModulePath && addModules.isEmpty()) {
            assert !isPatched;
=====
$ ls -l d
-rw-rw-r-- 1 iklam iklam 1349 Jul 26 15:31 com.greetings.jar
-rw-rw-r-- 1 iklam iklam 1136 Jul 26 15:31 org.astro.jar
$ java -p d -m com.greetings
Greetings world!
$ java -Xshare:dump -XX:SharedArchiveFile=hw.jsa --module-path=d
hasSplitPackages    = false
hasIncubatorModules = false


`hasIncubatorModules` was `true` in the bug report, but with the patch, both of these two values are `false`. This fix will unblock the following code when Calvin adds support for `--module-path` for the archived FMG.


        if (!hasSplitPackages && !hasIncubatorModules) {
            ArchivedBootLayer.archive(bootLayer);
        }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20818#issuecomment-2344470480

From iklam at openjdk.org  Wed Sep 11 19:18:07 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Sep 2024 19:18:07 GMT
Subject: RFR: 8338747: hasIncubatorModules needs to be generated when
 module resolution required at startup
In-Reply-To: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
References: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
Message-ID: <DSHOVvpVo81NvDHzpdI-nfRun7NlIXPOqeuLv5asZ4w=.12cd2552-4e5d-491e-8d7e-2f581f5db7b4@github.com>

On Mon, 2 Sep 2024 12:27:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR proposes changes to the ModuleBootstrap code that is used with CDS (Ahead-of-Time Class Loading & Linking in the future). At things stand, the module graph and boot layer can be archived at dump time (-Xshare:dump) when the initial module is the class path or the initial module is in the run-time image. Future work will extend this to deployments with an application module path or where additional root modules are specified with --add-modules. To get there we need the code that determines whether to archive is in one place, and it needs to know if the module graph contains incubator modules or split packages. 
> 
> Testing: tier1-tier6. There are no new tests, the changes don't expand or change what can be archived. Calvin has done some some testing with the change as it is needed for [JDK-8328313](https://bugs.openjdk.org/browse/JDK-8328313).

The logic seems to be correct (or at least err on the side of safety and recompute hasSplitPackages/hasIncubatorModules when we aren't 100% sure).

Small nit on the bug title: should it be changed to ".... when module resolution is required at startup"?

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20818#pullrequestreview-2298403770

From bpb at openjdk.org  Wed Sep 11 19:21:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 19:21:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
Message-ID: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>

On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> From a clean build in the CI with `mswsock.lib` removed:
>> 
>> 
>> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol
>> TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0
>
> did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89).
> There's no FileDispatcherImpl.obj in libnio.

Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755434973

From liach at openjdk.org  Wed Sep 11 19:24:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Sep 2024 19:24:09 GMT
Subject: Withdrawn: 8339875: MethodTypeDesc to reuse descriptor string from
 MethodType
In-Reply-To: <Xfdaa5WawpEz-f0wBiePT3ndXxp-vCD8ap-06JfNf0A=.8c54b7f4-f059-4109-b954-3fc80ad1c2bf@github.com>
References: <Xfdaa5WawpEz-f0wBiePT3ndXxp-vCD8ap-06JfNf0A=.8c54b7f4-f059-4109-b954-3fc80ad1c2bf@github.com>
Message-ID: <RKwuyGVJZgn9hh7XlOaZSk0w0vsyLD8IGEq5JIQXjAc=.0ab33abb-5030-40bb-8f16-5b79a9341c2f@github.com>

On Tue, 10 Sep 2024 23:24:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> A micro-optimization by sharing compatible String objects from MethodType (which itself is already deduplicated in a cache) to the generated MethodTypeDesc. This very slightly improves hashing performance by avoiding some string creation, hashing, and fast path equality via identity.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20942

From bpb at openjdk.org  Wed Sep 11 19:25:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 19:25:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>

On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097:
> 
>> 1095: 
>> 1096:     static {
>> 1097:         jdk.internal.loader.BootLoader.loadLibrary("net");
> 
> ...do we still need net here?

We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755440401

From naoto at openjdk.org  Wed Sep 11 19:30:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Sep 2024 19:30:12 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <joASYSZ81JN0MRVXGFbC1B4Ut7DGHQT7EVQrnkoNeXA=.6f32a60b-b0b2-4b1f-bbf4-76bbb27b0ff5@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
 <joASYSZ81JN0MRVXGFbC1B4Ut7DGHQT7EVQrnkoNeXA=.6f32a60b-b0b2-4b1f-bbf4-76bbb27b0ff5@github.com>
Message-ID: <Ktb7L4aq9wAx3rcZNhmCW8KAco5DaBqg8oVhxomNteI=.e4c72cc3-2962-430c-98f7-79b62ccd250c@github.com>

On Wed, 11 Sep 2024 18:33:59 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> maybe you can verify with a few simple edits to a tzdata file and building

Yes, that is exactly what I did for this testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2344538481

From naoto at openjdk.org  Wed Sep 11 19:30:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Sep 2024 19:30:13 GMT
Subject: Integrated: 8339803: Acknowledge case insensitive unambiguous keywords
 in tzdata files
In-Reply-To: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
Message-ID: <ONuMMk2yLlpzrKd76Td5bO4g8_1jOVEtRQ7XQOzxE-8=.3e150c3c-bc06-488d-89c9-46c947deaaab@github.com>

On Tue, 10 Sep 2024 19:45:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.

This pull request has now been integrated.

Changeset: 35a94b76
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35a94b769761bd923fe6db03be672f05c1a74c38
Stats:     41 lines in 4 files changed: 7 ins; 4 del; 30 mod

8339803: Acknowledge case insensitive unambiguous keywords in tzdata files

Reviewed-by: jlu, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/20940

From bpb at openjdk.org  Wed Sep 11 19:34:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 19:34:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6NvhSVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
 <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
 <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6Nvh
 SVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>
Message-ID: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com>

On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent.
>
> Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down.
> 
> Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio?

I've re-checked it and am running a CI job and will check it again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755467953

From ihse at openjdk.org  Wed Sep 11 19:34:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Sep 2024 19:34:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
 <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
Message-ID: <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6NvhSVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>

On Wed, 11 Sep 2024 19:18:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89).
>> There's no FileDispatcherImpl.obj in libnio.
>
> Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent.

Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down.

Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755463756

From vklang at openjdk.org  Wed Sep 11 20:05:08 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 11 Sep 2024 20:05:08 GMT
Subject: Integrated: 8299419: Thread.sleep(millis) may throw OOME
In-Reply-To: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
Message-ID: <d9EThMj4p0ULzYjZTfTV94DVuEKg5jhJC3HcgB9Jq6o=.479e533b-1f8a-40d8-b5d2-c7ce26ef171c@github.com>

On Mon, 9 Sep 2024 20:40:22 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR applies @AlanBateman's patch from the JBS issue.

This pull request has now been integrated.

Changeset: b0cff6b5
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0cff6b528af7a2de453dd05d1c9ecbe7e00dc20
Stats:     22 lines in 5 files changed: 3 ins; 14 del; 5 mod

8299419: Thread.sleep(millis) may throw OOME

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20923

From ccheung at openjdk.org  Wed Sep 11 21:02:05 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 11 Sep 2024 21:02:05 GMT
Subject: RFR: 8338747: hasIncubatorModules needs to be generated when
 module resolution required at startup
In-Reply-To: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
References: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
Message-ID: <xSrpevfl-eei68Lkj9VrOsvV-8t2KQHbIpGeBKO_hdk=.cc05bdc4-78df-4ef7-8c8b-bc364352d6a2@github.com>

On Mon, 2 Sep 2024 12:27:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR proposes changes to the ModuleBootstrap code that is used with CDS (Ahead-of-Time Class Loading & Linking in the future). At things stand, the module graph and boot layer can be archived at dump time (-Xshare:dump) when the initial module is the class path or the initial module is in the run-time image. Future work will extend this to deployments with an application module path or where additional root modules are specified with --add-modules. To get there we need the code that determines whether to archive is in one place, and it needs to know if the module graph contains incubator modules or split packages. 
> 
> Testing: tier1-tier6. There are no new tests, the changes don't expand or change what can be archived. Calvin has done some some testing with the change as it is needed for [JDK-8328313](https://bugs.openjdk.org/browse/JDK-8328313).

Thanks for the fix. I tried the patch together with my prototype for JDK-8328313 and sanity testing looks good.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20818#pullrequestreview-2298644516

From liach at openjdk.org  Wed Sep 11 23:36:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Sep 2024 23:36:19 GMT
Subject: RFR: 8339876: Move constant symbol caches to Utf8EntryImpl
Message-ID: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>

Some type descriptors are validated against generic utf8 entries, such as field or method types; we can cache a type descriptor wrapping the content of the utf8 entry if this entry is ever used as a type descriptor.

This patch is more of a code cleanup; it is performance neutral.

-------------

Commit messages:
 - 8339876: Move constant symbol caches to Utf8EntryImpl

Changes: https://git.openjdk.org/jdk/pull/20957/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20957&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339876
  Stats: 169 lines in 19 files changed: 56 ins; 82 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/20957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20957/head:pull/20957

PR: https://git.openjdk.org/jdk/pull/20957

From dholmes at openjdk.org  Thu Sep 12 01:11:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Sep 2024 01:11:06 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <CTFPuymBx5POEsNCfw2qKRebfpEWy9y7T-KwQmZ4OBY=.adb2f05b-e1b2-4d5a-987a-55250ff93d26@github.com>

On Wed, 11 Sep 2024 09:47:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Good cleanup.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20945#pullrequestreview-2299031033

From jpai at openjdk.org  Thu Sep 12 02:05:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 02:05:09 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <hqBwPMCdFXVg5ABQG9TuVcJvghRUvnvOZCdrng9iAEI=.31f53203-637b-4d1c-8a44-4235a0a5fbec@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

Thank you everyone for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20930#issuecomment-2345106667

From jpai at openjdk.org  Thu Sep 12 02:05:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 02:05:10 GMT
Subject: Integrated: 8339834: Replace usages of -mx and -ms in some tests
In-Reply-To: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
Message-ID: <xtv6kN1gsVAwNkjA2DLMx4vIra8LI3pxnZfd9f5k1JE=.090b792a-2532-4bc7-ab40-85026b57d443@github.com>

On Tue, 10 Sep 2024 09:46:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
> 
> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

This pull request has now been integrated.

Changeset: 1d392492
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d392492311daceeae12769cb9494eae63289853
Stats:     22 lines in 9 files changed: 0 ins; 5 del; 17 mod

8339834: Replace usages of -mx and -ms in some tests

Reviewed-by: aivanov, ascarpino, prr, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/20930

From bpb at openjdk.org  Thu Sep 12 02:10:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:00 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>

> 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 incrementally with one additional commit since the last revision:

  8337143: Clean up to address reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/4f47d5a6..853d3491

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05-06

  Stats: 20 lines in 9 files changed: 4 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bpb at openjdk.org  Thu Sep 12 02:10:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:02 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <GEoGSCqrJf90QYMcfFb8lE1Ebo-zidvIRtPsSkgBRd8=.cb63db12-612f-4d62-9859-98c3c2f8dd59@github.com>

On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> make/modules/java.base/Lib.gmk line 48:
> 
>> 46:     OPTIMIZATION := LOW, \
>> 47:     EXTRA_HEADER_DIRS := \
>> 48:         libjava/nio/ch, \
> 
> This appears to be unneeded

Agreed. See 853d349.

> src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> No changes in this file

There is one now. 853d349

> src/java.base/unix/native/libnio/ch/NIOUtil.c line 34:
> 
>> 32: #include "jvm.h"
>> 33: #include "jlong.h"
>> 34: #include "sun_nio_ch_IOUtil.h"
> 
> should this be NIOUtil?

Yes. See 853d349.

> src/java.base/windows/native/libnio/ch/NIOUtil.c line 41:
> 
>> 39: 
>> 40: JNIEXPORT jboolean JNICALL
>> 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed
> 
> unused

Removed. 853d349

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983126
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984164
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984274
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755985066

From bpb at openjdk.org  Thu Sep 12 02:10:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:02 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
Message-ID: <KWTkjBSr9ogLMEl2ii9baLUMiNy6H6v8GO3kjjx40t4=.d9340502-77e5-4087-92af-c7a5bcbc9c93@github.com>

On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 81:
>> 
>>> 79:         libjava/nio/ch \
>>> 80:         libnio/ch \
>>> 81:         libnio/fs \
>> 
>> libnio/fs is gone on all platforms other than aix; is this still necessary?
>
> We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I <dir>` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course.

Not changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983319

From bpb at openjdk.org  Thu Sep 12 02:10:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:02 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
 <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
 <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6Nvh
 SVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>
 <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com>
Message-ID: <8iOw1S8wQQ6G7-laGTbkZI5rnQjOZrbqv0iZ9BmThTY=.4baaded4-c285-45a2-83c1-d0fd7f3e7ef3@github.com>

On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down.
>> 
>> Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio?
>
> I've re-checked it and am running a CI job and will check it again.

Re-tests passed. See 853d349.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983781

From bpb at openjdk.org  Thu Sep 12 02:10:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:03 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>
 <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com>
Message-ID: <ZwzJfVdGexSdlhmip5DQS-vPZD8Ss3dwJtP8JNxMMbo=.aadd867f-67c4-4c95-82d5-211a15159416@github.com>

On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions.
>
> that's a good point. The comment might need to be updated to reflect that.

Comments added in 853d349.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983974

From bpb at openjdk.org  Thu Sep 12 02:10:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:03 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
Message-ID: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>

On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097:
>> 
>>> 1095: 
>>> 1096:     static {
>>> 1097:         jdk.internal.loader.BootLoader.loadLibrary("net");
>> 
>> ...do we still need net here?
>
> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit.

Moved to `NTLMAuthentication` static initializer. 853d349

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984949

From amitkumar at openjdk.org  Thu Sep 12 05:30:34 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 12 Sep 2024 05:30:34 GMT
Subject: RFR: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
Message-ID: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>

This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).

-------------

Commit messages:
 - problemlisted

Changes: https://git.openjdk.org/jdk/pull/20960/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20960&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339980
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20960/head:pull/20960

PR: https://git.openjdk.org/jdk/pull/20960

From jpai at openjdk.org  Thu Sep 12 05:30:42 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 05:30:42 GMT
Subject: RFR: 8339332: Clean up the java launcher code
Message-ID: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>

Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't preferab
 le.

The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.

With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.

Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and Instance Main Methods" have been instead moved into the Java code (in `LauncherHelper`) to simplify the launcher.

With these changes, tier testing of tier1 through tier8 has passed without issues. A new jtreg test has been added in this PR which reproduces the issue noted in https://bugs.openjdk.org/browse/JDK-8328995 and verifies the fix.

-------------

Commit messages:
 - comment cleanup
 - move ShowSplashScreen() to PostJVMInit()
 - 8339332: Clean up the java launcher code
 - 8328995: add a test case for launching a ZIP64 executable jar

Changes: https://git.openjdk.org/jdk/pull/20929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20929&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339332
  Stats: 991 lines in 11 files changed: 415 ins; 457 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/20929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20929/head:pull/20929

PR: https://git.openjdk.org/jdk/pull/20929

From jpai at openjdk.org  Thu Sep 12 05:34:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 05:34:03 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
Message-ID: <4gG6vj9-tbqCw4GVAmnZ0rSnjywGuNSm8LSUtRsaG10=.8c8eb3e7-ce37-4f3b-8a99-c8c8355baf04@github.com>

On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest.

I would like to note here that the mJRE feature is currently still supported (only) in JDK 8. What that means is, the `java` launcher from JDK 8 will parse jar files being launched to see if they specify a specific JRE version (even latest mainline version of JDK is allowed) and if it finds one, then the Java 8's launcher is expected to correctly launch the specified JRE. With the change that has been done in this PR, I have manually verified that a Java 8 launcher will still be able to launch the latest mainline JRE (and thus the application), even after the changes in this current PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20929#issuecomment-2345307704

From djelinski at openjdk.org  Thu Sep 12 06:27:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 12 Sep 2024 06:27:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
Message-ID: <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>

On Thu, 12 Sep 2024 02:10:00 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Clean up to address reviewer comments

Thanks for making the changes. LGTM, assuming that tests still pass.

One question in line.

src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221:

> 219: static futimesat_func* my_futimesat_func = NULL;
> 220: static futimens_func* my_futimens_func = NULL;
> 221: #ifndef _ALLBSD_SOURCE

This change looks unrelated. Was it intentional?

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2299319884
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1756202839

From alanb at openjdk.org  Thu Sep 12 06:29:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Sep 2024 06:29:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <mAUi6-QVv8CtF92LpJ9rAUSRCKU8s0V0-TVS8bS0PRI=.2bdeb7cf-8337-4c94-860b-6aa84036c129@github.com>

On Wed, 11 Sep 2024 09:47:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20945#pullrequestreview-2299324332

From dholmes at openjdk.org  Thu Sep 12 06:43:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Sep 2024 06:43:09 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
Message-ID: <d7KjApSnzqNcUlcl5oEnwS_OGiPyLlD78v-MpSOZ7Gs=.425785e6-25e4-43dc-9caa-c497657790d1@github.com>

On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't prefer
 able.
> 
> The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.
> 
> With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.
> 
> Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and Instance Main...

Just a few drive-by comments. This is all rather complex from a reviewers perspective - it is very hard to discern what code change relates to what you described in the PR. Can it be broken up into smaller chunks perhaps?

Aside: we do an awful lot of Java code execution in the launcher these days before we even get to load the real main class. I have to wonder how all this affects startup?

src/java.base/macosx/native/libjli/java_md_macosx.m line 88:

> 86:  * the command line or from the manifest of an executable jar file.
> 87:  * The vm selection options are not passed to the running
> 88:  * virtual machine; they must be screened out by the launcher.

The flowchart below seems to be out-of-date as I'm pretty sure no data-model selection is performed any more (no -d64).

src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 105:

> 103:                                 || !Modifier.isPublic(mods)
> 104:                                 || mainMethod.getParameterCount() != 1)
> 105:                 )) {

This seems a distinct fix rather than a "cleanup". ??

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 607:

> 605:         if (mainAttrs == null) {
> 606:             abort(null, "java.launcher.jar.error3", jarname);
> 607:         }

Why do we no longer need a null check?

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 1046:

> 1044:     // carries details about the application's main method and splash screen image path,
> 1045:     // that will be used by the native code in the launcher.
> 1046:     public record MainEntry (Class<?> mainClass, Method mainMethod,

Nit: no space before `(`.

src/java.base/share/native/libjli/java.c line 62:

> 60:  * A NOTE TO DEVELOPERS: For performance reasons it is important that
> 61:  * the program image remain relatively small until after
> 62:  * CreateExecutionEnvironment has finished its possibly recursive

Is recursion still a possibility?

src/java.base/share/native/libjli/java.c line 1138:

> 1136:         has_arg = IsOptionWithArgument(argc, argv);
> 1137:         if (JLI_StrCCmp(arg, "-version:") == 0) {
> 1138:             JLI_ReportErrorMessage(SPC_ERROR1);

Are these error message definitions, `SPC_ERROR1` etc, unused now?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20929#pullrequestreview-2299311631
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756196485
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756200162
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756205248
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756208934
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756209784
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756214113

From jpai at openjdk.org  Thu Sep 12 06:49:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 06:49:07 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
Message-ID: <mTv3pCsIaVnoP6eJaVkvCb_7sBr3mczIBFOQVI9vZzk=.58d634bc-efe6-4073-817c-765f1c77f901@github.com>

On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't prefer
 able.
> 
> The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.
> 
> With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.
> 
> Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and Instance Main...

Hello David,

> This is all rather complex from a reviewers perspective - it is very hard to discern what code change relates to what you described in the PR. Can it be broken up into smaller chunks perhaps?

That was my initial idea - to break this up into two or even three separate tasks. But those attempts did not lead to a clean state which I thought could be integrated independently. If you and others think that this still needs to be broken down, then I can revive those efforts to change this into separate tasks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20929#issuecomment-2345403699

From jpai at openjdk.org  Thu Sep 12 06:54:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 06:54:05 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <d7KjApSnzqNcUlcl5oEnwS_OGiPyLlD78v-MpSOZ7Gs=.425785e6-25e4-43dc-9caa-c497657790d1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
 <d7KjApSnzqNcUlcl5oEnwS_OGiPyLlD78v-MpSOZ7Gs=.425785e6-25e4-43dc-9caa-c497657790d1@github.com>
Message-ID: <d2f9ouPRbL7FSsv5CZYpQz1URagReNXSDFA7ToTXe1A=.5f955fec-02c7-4866-a5a3-36ff7a4f2ef6@github.com>

On Thu, 12 Sep 2024 06:39:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Aside: we do an awful lot of Java code execution in the launcher these days before we even get to load the real main class. I have to wonder how all this affects startup?

In addition to regular regression testing, I also ran existing internal startup benchmarks against this change. I noticed no observable regression or improvement with these changes.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 607:
> 
>> 605:         if (mainAttrs == null) {
>> 606:             abort(null, "java.launcher.jar.error3", jarname);
>> 607:         }
> 
> Why do we no longer need a null check?

The null check is still done, but it's now done before calling this private method. It's done here https://github.com/openjdk/jdk/pull/20929/files/abc3100078c2ab522054d1074d1cdc53c2879388#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226R848

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20929#issuecomment-2345411767
PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756234772

From jpai at openjdk.org  Thu Sep 12 07:06:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 07:06:06 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <d7KjApSnzqNcUlcl5oEnwS_OGiPyLlD78v-MpSOZ7Gs=.425785e6-25e4-43dc-9caa-c497657790d1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
 <d7KjApSnzqNcUlcl5oEnwS_OGiPyLlD78v-MpSOZ7Gs=.425785e6-25e4-43dc-9caa-c497657790d1@github.com>
Message-ID: <EJxExZrstoMKJwk8EtHFm_5wDnj37-PICYkkIwLmjqc=.dae1cace-3289-43c2-8e43-b509e3b04ee7@github.com>

On Thu, 12 Sep 2024 06:33:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't prefe
 rable.
>> 
>> The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.
>> 
>> With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.
>> 
>> Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and...
>
> src/java.base/share/native/libjli/java.c line 1138:
> 
>> 1136:         has_arg = IsOptionWithArgument(argc, argv);
>> 1137:         if (JLI_StrCCmp(arg, "-version:") == 0) {
>> 1138:             JLI_ReportErrorMessage(SPC_ERROR1);
> 
> Are these error message definitions, `SPC_ERROR1` etc, unused now?

The `SPC_ERROR1` and similar error messages were being thrown when the launcher arguments `-version:`, `-jre-restrict-search` and `-jre-no-restrict-search` were being parsed. That parsing used to happen in this `SelectVersion()` function which has been removed in the PR. The parsing of these arguments has been moved to the existing `ParseArguments` function where it continues to throw this `SPC_ERROR1` and other related error messages. So these error message definitions are still in use.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756252290

From duke at openjdk.org  Thu Sep 12 07:16:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 12 Sep 2024 07:16:04 GMT
Subject: RFR: 8339876: Move constant symbol caches to Utf8EntryImpl
In-Reply-To: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
References: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
Message-ID: <5GIGQYIy19RFIFdAORTUa7QxsOltaB5yXrqYIsPGKBs=.c2e580ee-905b-420d-a187-faf44e331c11@github.com>

On Wed, 11 Sep 2024 23:31:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some type descriptors are validated against generic utf8 entries, such as field or method types; we can cache a type descriptor wrapping the content of the utf8 entry if this entry is ever used as a type descriptor.
> 
> This patch is more of a code cleanup; it is performance neutral.

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 507:

> 505:     public MethodTypeEntry methodTypeEntry(MethodTypeDesc descriptor) {
> 506:         return methodTypeEntry(utf8Entry(descriptor));
> 507:     }

This?method?body can?be?moved to?[`ConstantPoolBuilder?::methodTypeEntry?(MethodTypeDesc)`] and?that?method be?made?`default` like?[`ConstantPoolBuilder?::classEntry?(ClassDesc)`], [`ConstantPoolBuilder?::packageEntry?(PackageDesc)`], and?[`ConstantPoolBuilder?::moduleEntry?(ModuleDesc)`].

[`ConstantPoolBuilder?::methodTypeEntry?(MethodTypeDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#methodTypeEntry(java.lang.constant.MethodTypeDesc)
[`ConstantPoolBuilder?::classEntry?(ClassDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#classEntry(java.lang.constant.ClassDesc)
[`ConstantPoolBuilder?::packageEntry?(PackageDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#packageEntry(java.lang.constant.PackageDesc)
[`ConstantPoolBuilder?::moduleEntry?(ModuleDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#moduleEntry(java.lang.constant.ModuleDesc)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20957#discussion_r1756268000

From alanb at openjdk.org  Thu Sep 12 07:46:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Sep 2024 07:46:05 GMT
Subject: RFR: 8338747: hasIncubatorModules needs to be generated when
 module resolution required at startup
In-Reply-To: <DSHOVvpVo81NvDHzpdI-nfRun7NlIXPOqeuLv5asZ4w=.12cd2552-4e5d-491e-8d7e-2f581f5db7b4@github.com>
References: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
 <DSHOVvpVo81NvDHzpdI-nfRun7NlIXPOqeuLv5asZ4w=.12cd2552-4e5d-491e-8d7e-2f581f5db7b4@github.com>
Message-ID: <S0QCpjUGI1LiXrdqMWyhigvef9x1HvOkaT3Uc2c1_SE=.0947ffb0-fb07-4fb9-81ed-84c8308608f7@github.com>

On Wed, 11 Sep 2024 19:15:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The logic seems to be correct (or at least err on the side of safety and recompute hasSplitPackages/hasIncubatorModules when we aren't 100% sure).

Just to say a bit more about this. When you specify an application module path to the java launcher then you don't know in advance which modules on the module path will be resolved and whether an incubator module will be resolved. So if startup generates a new Configuration then it has to be checked for incubator modules so that a warning can be printed. The issue we have isn't really a bug, it's that the prototype CDS changes piggyback on the flag used to say if we need to check for incubator modules. With the changes, the flag is renamed to mayContainIncubatorModules to avoid any confusion. As part of dumping, the generated Configuration is checked for incubating modules so that archiving of the boot layer (or "FMG" as CDS refers to it) can be skipped.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20818#issuecomment-2345503053

From redestad at openjdk.org  Thu Sep 12 08:21:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Sep 2024 08:21:09 GMT
Subject: RFR: 8339876: Move constant symbol caches to Utf8EntryImpl
In-Reply-To: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
References: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
Message-ID: <b1UdOVOJSMKYsgrfeIok6CfmhkNmGd87Xh5ytiTMZpo=.1a8b1adc-933c-43ce-b3c5-9c93ef7b975f@github.com>

On Wed, 11 Sep 2024 23:31:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some type descriptors are validated against generic utf8 entries, such as field or method types; we can cache a type descriptor wrapping the content of the utf8 entry if this entry is ever used as a type descriptor.
> 
> This patch is more of a code cleanup; it is performance neutral.

This looks good!

As you say it seems pretty much neutral on current startup tests, but unlocks future performance gains by making pool factory methods taking `Utf8Entry` more appealing.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20957#pullrequestreview-2299555235

From alanb at openjdk.org  Thu Sep 12 08:51:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Sep 2024 08:51:09 GMT
Subject: Integrated: 8338747: hasIncubatorModules needs to be generated when
 module resolution required at startup
In-Reply-To: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
References: <Fr71nzDgsCVXUDKgn2g5MB2MVLLV5G45B1C-vZFTkbU=.2fd5c893-eedd-446c-ae33-fc02467b89ca@github.com>
Message-ID: <YYTMDdNVfiuSM46zhrg2R__tR_fuk8a6sFJZixedkjY=.de6fb26c-4df6-4116-972b-63e46e90b355@github.com>

On Mon, 2 Sep 2024 12:27:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR proposes changes to the ModuleBootstrap code that is used with CDS (Ahead-of-Time Class Loading & Linking in the future). At things stand, the module graph and boot layer can be archived at dump time (-Xshare:dump) when the initial module is the class path or the initial module is in the run-time image. Future work will extend this to deployments with an application module path or where additional root modules are specified with --add-modules. To get there we need the code that determines whether to archive is in one place, and it needs to know if the module graph contains incubator modules or split packages. 
> 
> Testing: tier1-tier6. There are no new tests, the changes don't expand or change what can be archived. Calvin has done some some testing with the change as it is needed for [JDK-8328313](https://bugs.openjdk.org/browse/JDK-8328313).

This pull request has now been integrated.

Changeset: 1b17e0b1
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b17e0b133cab44029333c832bd046b338ede581
Stats:     72 lines in 1 file changed: 31 ins; 21 del; 20 mod

8338747: hasIncubatorModules needs to be generated when module resolution required at startup

Reviewed-by: iklam, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/20818

From eirbjo at openjdk.org  Thu Sep 12 08:53:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 12 Sep 2024 08:53:12 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
Message-ID: <7FG2vGCmeuxtM22pE4vOohNb9iL621y6XnCLoE-bms0=.90ffdebb-e094-4c47-bcfb-244bb5386f49@github.com>

On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't prefer
 able.
> 
> The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.
> 
> With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.
> 
> Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and Instance Main...

test/jdk/tools/launcher/Zip64ExecutableJarTest.java line 167:

> 165:     private static class SparseOutputStream extends FilterOutputStream {
> 166:         private final FileChannel channel;
> 167:         private boolean sparse = true; // if true then contents will be written as sparse holes

Would be nice if we could make the file produced in this test a valid ZIP file, that is narrowing the sparse mode scope to just the writing of the big entry data payload.

That way it's easier to inspect the file independently, using tools such as `zipdetails`

Consider fixing this by making `SparseOutputStream.sparse` false by default, setting it to true before the write loop and back to false after. That way the ZIP will include the Local File Header and the Data Descriptor for the entry.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20929#discussion_r1756429667

From lbourges at openjdk.org  Thu Sep 12 09:07:15 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 12 Sep 2024 09:07:15 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: <BOIX6jv-2_jfC0Xl77gbh9nIiZ4EJuDRtWzGAbdLCXY=.3645739a-38b8-4542-b25c-527bb3900d3d@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)

Keep alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2345694501

From pminborg at openjdk.org  Thu Sep 12 09:50:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 09:50:24 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v11]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <NbOggdKUtZHSpmq2vuI9XSbm3yEfMBqRHxbAqEQr4O8=.5bf2e109-a2b0-474d-bfe2-95ed46cfdbda@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

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 22 additional commits since the last revision:

 - Always use Java for mismatch by default on a64
 - Only use unrolling on a64
 - Unroll loop and move method
 - Merge branch 'master' into mismatch-performance2
 - Use unaligned ops and rename benchmarks
 - Fix errors in a benchmark
 - Lower the mismatch threshold
 - Move method to SegmentBulkOperations and fix benchmark
 - Merge branch 'master' into mismatch-performance2
 - Consolidate logic in one method
 - ... and 12 more: https://git.openjdk.org/jdk/compare/9f3c9169...a75dc159

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/f40573c4..a75dc159

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=09-10

  Stats: 9514 lines in 321 files changed: 5283 ins; 2651 del; 1580 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

PR: https://git.openjdk.org/jdk/pull/20848

From pminborg at openjdk.org  Thu Sep 12 09:50:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 09:50:24 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v10]
In-Reply-To: <u2GPnd_uLMh7y_oOWKYckUOLkHLAplLlYyAcVkYKjMw=.0265e9bc-cc52-475f-bf91-b7e7c470f8ad@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <u2GPnd_uLMh7y_oOWKYckUOLkHLAplLlYyAcVkYKjMw=.0265e9bc-cc52-475f-bf91-b7e7c470f8ad@github.com>
Message-ID: <betJvaDIb_vHk8LxK8vMtNC9omph7ROwyuUQIDoESMs=.a4b02d24-ef89-4d11-9b0a-5ca121b80e7d@github.com>

On Fri, 6 Sep 2024 11:52:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use unaligned ops and rename benchmarks

I've added manual loop-unrolling for Aarch64 (only). This gives a significant performance boost for larger segments:

![image](https://github.com/user-attachments/assets/e477e4a6-8d4d-403d-91f8-978496f10021)

On x64, manual unrolling is not necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20848#issuecomment-2345784880

From jpai at openjdk.org  Thu Sep 12 10:17:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 10:17:05 GMT
Subject: RFR: 8339332: Clean up the java launcher code
In-Reply-To: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
Message-ID: <6E9gNym-T-oNsWdLLWnzbvdeymv6vh4P1OST_qHUi0g=.f2eecee4-0e4a-416c-801c-43d5b1381b48@github.com>

On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't prefer
 able.
> 
> The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.
> 
> With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.
> 
> Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and Instance Main...

I am going to take a step back here. David is right that this PR can be difficult to review since it involves more than one reason for change. When I initially attempted to split this up, I didn't have the complete picture of what all changes would be needed to reach the end goal of not having the C code doing the jar manifest parsing. However, I am now aware of what's required, so I think I should be able to split this up into separate 2 or 3 tasks and more isolated PRs to reach there. I think that will help review the changes more confidently. 

I'm going to put this PR in draft mode and very likely will withdraw it shortly. I will open separate PRs containing the individual changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20929#issuecomment-2345842877

From rgiulietti at openjdk.org  Thu Sep 12 10:32:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Sep 2024 10:32:11 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
Message-ID: <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>

On Wed, 11 Sep 2024 15:51:25 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use supported annotation by jtreg in tests

src/java.base/share/classes/java/math/MutableBigInteger.java line 709:

> 707:      * Assumes that intLen > 0, n > 0 for speed
> 708:      */
> 709:     private final void primitiveRightShift(int n) {

Plz remove `final` from `private` primitive shift methods. (The `final`s were there long before your PR.)

src/java.base/share/classes/java/math/MutableBigInteger.java line 722:

> 720:      * {@code (resPos <= offset || resPos >= offset + intLen)}.
> 721:      */
> 722:     private final void primitiveRightShift(int n, int[] result, int resPos) {

Suggestion:

    private final void primitiveRightShift(int n, int[] result, int resOff) {

or something more similar to "offset".

Same for the left shift.

src/java.base/share/classes/java/math/MutableBigInteger.java line 753:

> 751:      * {@code (resPos <= offset || resPos >= offset + intLen)}.
> 752:      */
> 753:     private final void primitiveLeftShift(int n, int[] result, int resPos) {

I think this method can be made more symmetrical w.r.t. `primitiveRightShift()` if starting from the right (least significant `int`).

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 49:

> 47: 
> 48:     static final int ORDER_SMALL = 60;
> 49:     static final int ORDER_MEDIUM = 100;

Only now it occurs to me that these can be `private`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756584630
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756587300
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756584738
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756584885

From rgiulietti at openjdk.org  Thu Sep 12 10:32:12 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Sep 2024 10:32:12 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <c0329jZF4HvMc4aHMw5Dg3OyK0S2cVyIIMJaEGrCDBw=.cbdccfa9-414b-4baf-995f-e3e6973adea7@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
 <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
 <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>
 <c0329jZF4HvMc4aHMw5Dg3OyK0S2cVyIIMJaEGrCDBw=.cbdccfa9-414b-4baf-995f-e3e6973adea7@github.com>
Message-ID: <cjZmTWkShwaYPsn5ou2kQ1OeU3fHAI3cMXWjVR66V9E=.c62c82ec-2ec5-4639-8e3b-f1ea6d4f139a@github.com>

On Wed, 11 Sep 2024 15:34:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The test cases of the code are the same of the test class for `BigInteger.shiftLeft()`.
>
> I see (with obvious adaptations and one more `case`).

The implementation of the shift methods in `MutableBigInteger` has several control flow paths, depending on whether a new `int[]` is needed, whether `arraycopy()` can be used, etc.

Relying on random tests is good if the "search space" (the number of control flow paths) is too big for a systematic approach. But here I think it should be possible to exercise all paths with a dozen or so well targeted tests, in addition to the existing ones.

These are white-box tests, so the internal structure of the algorithms is supposed to be known and this knowledge should be exploited in trying to hit the weak points, if there are.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756585001

From pminborg at openjdk.org  Thu Sep 12 10:54:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 10:54:47 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v12]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Fix yet another typo
 - Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/a75dc159..e93d334a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

PR: https://git.openjdk.org/jdk/pull/20848

From duke at openjdk.org  Thu Sep 12 11:09:06 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 11:09:06 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
 <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
Message-ID: <xmKLHZ0U6lMdLcXt3fmPRL_F66BzMLi9HpBLSVssY7Q=.518ba8a1-136c-4fae-94c7-03671f43b35a@github.com>

On Thu, 12 Sep 2024 10:27:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use supported annotation by jtreg in tests
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 753:
> 
>> 751:      * {@code (resPos <= offset || resPos >= offset + intLen)}.
>> 752:      */
>> 753:     private final void primitiveLeftShift(int n, int[] result, int resPos) {
> 
> I think this method can be made more symmetrical w.r.t. `primitiveRightShift()` if starting from the right (least significant `int`).

Yes, it could, but the problem is that in this way the precondition `(resPos <= offset || resPos >= offset + intLen)` is no longer correct, and in particular `resPos <= offset` is used by `MBI.leftShift()` if `result == value`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756641412

From pminborg at openjdk.org  Thu Sep 12 11:17:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 11:17:10 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <mlBmQQGkv7KoKZIbVKfA96ZTM-9W57j9Mme26C-QvtE=.73bd5377-ecef-41bf-8df3-6af9aad3e53b@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <mlBmQQGkv7KoKZIbVKfA96ZTM-9W57j9Mme26C-QvtE=.73bd5377-ecef-41bf-8df3-6af9aad3e53b@github.com>
Message-ID: <o9LHhcayIqGFvwQKfjdOJF2llZjoRS-xIRKyEWBLSL4=.bc9b363e-21f5-4b2e-b4d1-a7c95d797c1d@github.com>

On Fri, 6 Sep 2024 12:05:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Wdyt about the benchmark I have added at [#20829 (comment)](https://github.com/openjdk/jdk/pull/20829#issuecomment-2326404582)?

Added https://bugs.openjdk.org/browse/JDK-8339999

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20829#issuecomment-2346008727

From duke at openjdk.org  Thu Sep 12 11:20:11 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Thu, 12 Sep 2024 11:20:11 GMT
Subject: RFR: 8338591: Improve performance of MemorySegment::copy
In-Reply-To: <o9LHhcayIqGFvwQKfjdOJF2llZjoRS-xIRKyEWBLSL4=.bc9b363e-21f5-4b2e-b4d1-a7c95d797c1d@github.com>
References: <1J1vDTjYYo9UqYh4y8gP_4ZXnseTuB2ezDohx4zUYkc=.0d394c85-8f5a-4427-9a06-487ba4af974e@github.com>
 <mlBmQQGkv7KoKZIbVKfA96ZTM-9W57j9Mme26C-QvtE=.73bd5377-ecef-41bf-8df3-6af9aad3e53b@github.com>
 <o9LHhcayIqGFvwQKfjdOJF2llZjoRS-xIRKyEWBLSL4=.bc9b363e-21f5-4b2e-b4d1-a7c95d797c1d@github.com>
Message-ID: <zM271PPm-e7Ll-XLsyCNlX5JryIpjhDAdGweHPG09AI=.8759ac9f-ea74-4531-bdd2-42045bd6dac7@github.com>

On Thu, 12 Sep 2024 11:14:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> Wdyt about the benchmark I have added at [#20829 (comment)](https://github.com/openjdk/jdk/pull/20829#issuecomment-2326404582)? Sadly I didn't yet run against this PR
>> 
>> Let's see what we can do about this later.
>
>> Wdyt about the benchmark I have added at [#20829 (comment)](https://github.com/openjdk/jdk/pull/20829#issuecomment-2326404582)?
> 
> Added https://bugs.openjdk.org/browse/JDK-8339999

thanks @minborg !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20829#issuecomment-2346014609

From duke at openjdk.org  Thu Sep 12 11:26:11 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 11:26:11 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
 <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
Message-ID: <lElKq6b7opPtdriovm6nnNIIGxkjzS6-vhN49O_Cz0Y=.a4a0ea98-2c67-437f-a5cc-50142416b1ae@github.com>

On Thu, 12 Sep 2024 10:29:24 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use supported annotation by jtreg in tests
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 722:
> 
>> 720:      * {@code (resPos <= offset || resPos >= offset + intLen)}.
>> 721:      */
>> 722:     private final void primitiveRightShift(int n, int[] result, int resPos) {
> 
> Suggestion:
> 
>     private final void primitiveRightShift(int n, int[] result, int resOff) {
> 
> or something more similar to "offset".
> 
> Same for the left shift.

What about `resFrom`, like the old `MBI.copyAndshift()` method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756665227

From duke at openjdk.org  Thu Sep 12 11:26:11 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 11:26:11 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <cjZmTWkShwaYPsn5ou2kQ1OeU3fHAI3cMXWjVR66V9E=.c62c82ec-2ec5-4639-8e3b-f1ea6d4f139a@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
 <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
 <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>
 <c0329jZF4HvMc4aHMw5Dg3OyK0S2cVyIIMJaEGrCDBw=.cbdccfa9-414b-4baf-995f-e3e6973adea7@github.com>
 <cjZmTWkShwaYPsn5ou2kQ1OeU3fHAI3cMXWjVR66V9E=.c62c82ec-2ec5-4639-8e3b-f1ea6d4f139a@github.com>
Message-ID: <6iHzs6cZovf6Rg3xej1GZ8Y0X7WobJwwbL0_9N7bSZI=.fbcbd2ee-3a67-4bfd-9e85-a68b5ea8397b@github.com>

On Thu, 12 Sep 2024 10:27:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I see (with obvious adaptations and one more `case`).
>
> The implementation of the shift methods in `MutableBigInteger` has several control flow paths, depending on whether a new `int[]` is needed, whether `arraycopy()` can be used, etc.
> 
> Relying on random tests is good if the "search space" (the number of control flow paths) is too big for a systematic approach. But here I think it should be possible to exercise all paths with a dozen or so well targeted tests, in addition to the existing ones.
> 
> These are white-box tests, so the internal structure of the algorithms is supposed to be known and this knowledge should be exploited in trying to hit the weak points, if there are.

So, a test should be done for every possible path of computation of `MBI.leftShift()` method...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756662312

From eirbjo at openjdk.org  Thu Sep 12 11:28:20 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 12 Sep 2024 11:28:20 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v5]
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> The changes in this PR makes `UTF8ZipCoder.compare` the only caller of `ZipCoder.hasTrailingSlash`, so this method is made private and the implementation in the base class retired.
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Add comment where getEntry calls Source::getEntryPos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20939/files
  - new: https://git.openjdk.org/jdk/pull/20939/files/f24b833a..427c34cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20939&range=03-04

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20939/head:pull/20939

PR: https://git.openjdk.org/jdk/pull/20939

From lancea at openjdk.org  Thu Sep 12 11:33:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 12 Sep 2024 11:33:06 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v5]
In-Reply-To: <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>
Message-ID: <Fr7RX_KeCQEgQfhpiySIFJdUqI43FsLi-f1eVf-inbE=.281b6327-eadc-45c8-bd11-ff98d44da5be@github.com>

On Thu, 12 Sep 2024 11:28:20 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
>> 
>> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
>> 
>> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
>> 
>> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
>> 
>> Baseline:
>> 
>> 
>> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
>> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
>> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
>> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
>> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
>> 
>> The changes in this PR makes `UTF8ZipCoder.compare` the only caller of `ZipCoder.hasTrailingSlash`, so this method is made private and the implementation in the base class retired.
>> 
>> This purely a cleanup and optimization PR, no functional tests are changed or added.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment where getEntry calls Source::getEntryPos

thank you for the clean up Eirik, I think the changes look good overall.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20939#pullrequestreview-2300024386

From eirbjo at openjdk.org  Thu Sep 12 11:33:07 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 12 Sep 2024 11:33:07 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v5]
In-Reply-To: <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>
Message-ID: <wTeTTpqMuHs6NKwPHcQzUeSDPBbkAEBqhs7bE4Hd1E0=.de86f70e-21f9-4796-b06d-03039039b92f@github.com>

On Thu, 12 Sep 2024 11:28:20 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
>> 
>> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
>> 
>> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
>> 
>> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
>> 
>> Baseline:
>> 
>> 
>> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
>> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
>> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
>> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
>> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
>> 
>> The changes in this PR makes `UTF8ZipCoder.compare` the only caller of `ZipCoder.hasTrailingSlash`, so this method is made private and the implementation in the base class retired.
>> 
>> This purely a cleanup and optimization PR, no functional tests are changed or added.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment where getEntry calls Source::getEntryPos

For the benefit of future maintainers, I added a code comment where `ZipFile::getEntry` calls `Source::getEntryPos`, pointing out that the resolved name from the CEN may differ with a trailing slash.

This reminds me that `getEntryPos` is maybe not a great name. Perhaps something like `lookupEntry` would be more honest about the non-trivial logic involved. But perhaps that is for another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20939#issuecomment-2346038907

From pminborg at openjdk.org  Thu Sep 12 11:37:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 11:37:06 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v12]
In-Reply-To: <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
Message-ID: <0Q4xF0evkQkAxOdyL5NxzHm59SxPnX058ixbVJXaBSk=.420303c0-3f26-4772-ba6d-17c0be7bf2c1@github.com>

On Thu, 12 Sep 2024 10:54:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix yet another typo
>  - Fix typo

Here are some other benchmarks:

![image](https://github.com/user-attachments/assets/d6d0ef15-d768-4424-9dad-cbe43c139094)

![image](https://github.com/user-attachments/assets/8cbce3cd-0bff-4276-ab51-041c787e1bab)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20848#issuecomment-2346040710

From mcimadamore at openjdk.org  Thu Sep 12 11:37:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Sep 2024 11:37:07 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v12]
In-Reply-To: <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
Message-ID: <b6YpYZuRdn6Kv2oDSPkb2S33S3rEXVOBJTt0wCejerk=.2c89b6bf-f6b4-434f-9d67-3439bd763b4c@github.com>

On Thu, 12 Sep 2024 10:54:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix yet another typo
>  - Fix typo

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 204:

> 202:         // This gives about 20% performance increase for large values of `length`.
> 203:         // On non-Aarch64 architectures, the unroll code will be eliminated at compile time.
> 204:         if (Architecture.isAARCH64() && NATIVE_THRESHOLD_MISMATCH > 64) {

I'm a bit opposed to this - as it goes in the direction to add a lot of transient complexity when in reality the underlying issue is that aarch64 mismatch intrinsics should be fixed. Tinkering with thresholds is borderline, but still acceptable - having different implementations one per platform starts to look "more wrong".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1756674946

From mcimadamore at openjdk.org  Thu Sep 12 11:37:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Sep 2024 11:37:07 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v12]
In-Reply-To: <b6YpYZuRdn6Kv2oDSPkb2S33S3rEXVOBJTt0wCejerk=.2c89b6bf-f6b4-434f-9d67-3439bd763b4c@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
 <b6YpYZuRdn6Kv2oDSPkb2S33S3rEXVOBJTt0wCejerk=.2c89b6bf-f6b4-434f-9d67-3439bd763b4c@github.com>
Message-ID: <kVgsp4VBzxe0g3udZrNkdqOujJghiig0Q49EmDPIN-U=.c0fbcbfa-e789-456a-b60d-408c376f0e62@github.com>

On Thu, 12 Sep 2024 11:30:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix yet another typo
>>  - Fix typo
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 204:
> 
>> 202:         // This gives about 20% performance increase for large values of `length`.
>> 203:         // On non-Aarch64 architectures, the unroll code will be eliminated at compile time.
>> 204:         if (Architecture.isAARCH64() && NATIVE_THRESHOLD_MISMATCH > 64) {
> 
> I'm a bit opposed to this - as it goes in the direction to add a lot of transient complexity when in reality the underlying issue is that aarch64 mismatch intrinsics should be fixed. Tinkering with thresholds is borderline, but still acceptable - having different implementations one per platform starts to look "more wrong".

In other words, I don't think the goal of this (and related) PR is "improve mismatch so that it blows other alternatives - like Unsafe, or array" out of the water - as much as it is "make sure that using MemorySegment::mismatch is competitive with other offerings".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1756678756

From mcimadamore at openjdk.org  Thu Sep 12 11:37:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Sep 2024 11:37:08 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v12]
In-Reply-To: <kVgsp4VBzxe0g3udZrNkdqOujJghiig0Q49EmDPIN-U=.c0fbcbfa-e789-456a-b60d-408c376f0e62@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
 <b6YpYZuRdn6Kv2oDSPkb2S33S3rEXVOBJTt0wCejerk=.2c89b6bf-f6b4-434f-9d67-3439bd763b4c@github.com>
 <kVgsp4VBzxe0g3udZrNkdqOujJghiig0Q49EmDPIN-U=.c0fbcbfa-e789-456a-b60d-408c376f0e62@github.com>
Message-ID: <u2Ni-W-OPwVgDma7pxmP1nERla0ZfQzOufn_n0aqdbY=.dc8b40f6-516b-4072-a751-051afb2c20e9@github.com>

On Thu, 12 Sep 2024 11:32:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 204:
>> 
>>> 202:         // This gives about 20% performance increase for large values of `length`.
>>> 203:         // On non-Aarch64 architectures, the unroll code will be eliminated at compile time.
>>> 204:         if (Architecture.isAARCH64() && NATIVE_THRESHOLD_MISMATCH > 64) {
>> 
>> I'm a bit opposed to this - as it goes in the direction to add a lot of transient complexity when in reality the underlying issue is that aarch64 mismatch intrinsics should be fixed. Tinkering with thresholds is borderline, but still acceptable - having different implementations one per platform starts to look "more wrong".
>
> In other words, I don't think the goal of this (and related) PR is "improve mismatch so that it blows other alternatives - like Unsafe, or array" out of the water - as much as it is "make sure that using MemorySegment::mismatch is competitive with other offerings".

Then, an interesting part of these PRs is that we have uncovered quite a lot of issues both with our intrinsics (e.g. `fill` is not vectorized and works badly on Windows, mismatch works poorly on aarch64) *and* missed optimization opportunities - e.g. "short" segment loops are not optimized as tightly as they could. But it is not the job of these PRs to fix all these issues. The main focus remain: for small sizes it is not worth going down intrinsics-lane. Let's stick to it (in the interest of keeping the review focused).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1756682363

From rgiulietti at openjdk.org  Thu Sep 12 12:05:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Sep 2024 12:05:11 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <lElKq6b7opPtdriovm6nnNIIGxkjzS6-vhN49O_Cz0Y=.a4a0ea98-2c67-437f-a5cc-50142416b1ae@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
 <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
 <lElKq6b7opPtdriovm6nnNIIGxkjzS6-vhN49O_Cz0Y=.a4a0ea98-2c67-437f-a5cc-50142416b1ae@github.com>
Message-ID: <JMU9vClq0rI6UadJgOECSNRYZMD6YCw4ZSK8Hm7czwA=.3ca85dbd-c816-41c0-9588-8c6f6f82717c@github.com>

On Thu, 12 Sep 2024 11:23:24 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 722:
>> 
>>> 720:      * {@code (resPos <= offset || resPos >= offset + intLen)}.
>>> 721:      */
>>> 722:     private final void primitiveRightShift(int n, int[] result, int resPos) {
>> 
>> Suggestion:
>> 
>>     private final void primitiveRightShift(int n, int[] result, int resOff) {
>> 
>> or something more similar to "offset".
>> 
>> Same for the left shift.
>
> What about `resFrom`, like the old `MBI.copyAndshift()` method?

Up to you, the current `resPos` is OK as well.

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 753:
>> 
>>> 751:      * {@code (resPos <= offset || resPos >= offset + intLen)}.
>>> 752:      */
>>> 753:     private final void primitiveLeftShift(int n, int[] result, int resPos) {
>> 
>> I think this method can be made more symmetrical w.r.t. `primitiveRightShift()` if starting from the right (least significant `int`).
>
> Yes, it could, but the problem is that in this way the precondition `(resPos <= offset || resPos >= offset + intLen)` would be no longer correct, and in particular `resPos <= offset` is used by `MBI.leftShift()` if `result == value`.

I mean something like

    private void primitiveRightShift(int n, int[] result, int resPos) {
        int[] val = value;
        int n2 = 32 - n;
        int c = 0;
        for (int i = 0; i < intLen; i++) {
            int b = val[offset + i];
            result[resPos + i] = c << n2 | b >>> n;
            c = b;
        }
    }

and

    private void primitiveLeftShift(int n, int[] result, int resPos) {
        int[] val = value;
        int n2 = 32 - n;
        int c = 0;
        for (int i = intLen - 1; i >= 0; i--) {
            int b = val[offset + i];
            result[resPos + i] = c >>> n2 | b << n;
            c = b;
        }

They are compatible with the precondition, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756722886
PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756721676

From liach at openjdk.org  Thu Sep 12 12:23:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Sep 2024 12:23:08 GMT
Subject: RFR: 8339876: Move constant symbol caches to Utf8EntryImpl
In-Reply-To: <5GIGQYIy19RFIFdAORTUa7QxsOltaB5yXrqYIsPGKBs=.c2e580ee-905b-420d-a187-faf44e331c11@github.com>
References: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
 <5GIGQYIy19RFIFdAORTUa7QxsOltaB5yXrqYIsPGKBs=.c2e580ee-905b-420d-a187-faf44e331c11@github.com>
Message-ID: <xbbL5ZVH1MaVn5BiMOk0BSDEQECREnsbHTizrl--SfM=.f6ef0ed6-e6e5-45c4-afc4-bce2881bcca1@github.com>

On Thu, 12 Sep 2024 07:13:08 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Some type descriptors are validated against generic utf8 entries, such as field or method types; we can cache a type descriptor wrapping the content of the utf8 entry if this entry is ever used as a type descriptor.
>> 
>> This patch is more of a code cleanup; it is performance neutral.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 507:
> 
>> 505:     public MethodTypeEntry methodTypeEntry(MethodTypeDesc descriptor) {
>> 506:         return methodTypeEntry(utf8Entry(descriptor));
>> 507:     }
> 
> This?method?body can?be?moved to?[`ConstantPoolBuilder?::methodTypeEntry?(MethodTypeDesc)`] and?that?method be?made?`default` like?[`ConstantPoolBuilder?::classEntry?(ClassDesc)`], [`ConstantPoolBuilder?::packageEntry?(PackageDesc)`], and?[`ConstantPoolBuilder?::moduleEntry?(ModuleDesc)`].
> 
> [`ConstantPoolBuilder?::methodTypeEntry?(MethodTypeDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#methodTypeEntry(java.lang.constant.MethodTypeDesc)
> [`ConstantPoolBuilder?::classEntry?(ClassDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#classEntry(java.lang.constant.ClassDesc)
> [`ConstantPoolBuilder?::packageEntry?(PackageDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#packageEntry(java.lang.constant.PackageDesc)
> [`ConstantPoolBuilder?::moduleEntry?(ModuleDesc)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#moduleEntry(java.lang.constant.ModuleDesc)

too lazy to file a csr...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20957#discussion_r1756749044

From rgiulietti at openjdk.org  Thu Sep 12 12:25:05 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Sep 2024 12:25:05 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <6iHzs6cZovf6Rg3xej1GZ8Y0X7WobJwwbL0_9N7bSZI=.fbcbd2ee-3a67-4bfd-9e85-a68b5ea8397b@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
 <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
 <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>
 <c0329jZF4HvMc4aHMw5Dg3OyK0S2cVyIIMJaEGrCDBw=.cbdccfa9-414b-4baf-995f-e3e6973adea7@github.com>
 <cjZmTWkShwaYPsn5ou2kQ1OeU3fHAI3cMXWjVR66V9E=.c62c82ec-2ec5-4639-8e3b-f1ea6d4f139a@github.com>
 <6iHzs6cZovf6Rg3xej1GZ8Y0X7WobJwwbL0_9N7bSZI=.fbcbd2ee-3a67-4bfd-9e85-a68b5ea8397b@github.com>
Message-ID: <K2itlbEquuFGrRMCCGVF3ONFS4Om5G1DOy81J_paYyo=.8d400645-afca-40a3-887c-229a6335f667@github.com>

On Thu, 12 Sep 2024 11:21:10 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The implementation of the shift methods in `MutableBigInteger` has several control flow paths, depending on whether a new `int[]` is needed, whether `arraycopy()` can be used, etc.
>> 
>> Relying on random tests is good if the "search space" (the number of control flow paths) is too big for a systematic approach. But here I think it should be possible to exercise all paths with a dozen or so well targeted tests, in addition to the existing ones.
>> 
>> These are white-box tests, so the internal structure of the algorithms is supposed to be known and this knowledge should be exploited in trying to hit the weak points, if there are.
>
> So, a test should be done for every possible path of computation of `MBI.leftShift()` method...

Looking at the code of `leftShift()` alone, I roughly count a dozen or so paths.
But if you feel confident that the random tests cover all paths over several executions with high probability and that no corner cases are left out, then they might suffice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756752098

From duke at openjdk.org  Thu Sep 12 12:30:07 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 12:30:07 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <JMU9vClq0rI6UadJgOECSNRYZMD6YCw4ZSK8Hm7czwA=.3ca85dbd-c816-41c0-9588-8c6f6f82717c@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
 <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
 <lElKq6b7opPtdriovm6nnNIIGxkjzS6-vhN49O_Cz0Y=.a4a0ea98-2c67-437f-a5cc-50142416b1ae@github.com>
 <JMU9vClq0rI6UadJgOECSNRYZMD6YCw4ZSK8Hm7czwA=.3ca85dbd-c816-41c0-9588-8c6f6f82717c@github.com>
Message-ID: <ie7d3NC-zvF004fnO5L2xhA1DnGtiaAqcfp1OwY3gPQ=.f2aa1d2f-b5a8-4ac3-a393-f5426c07d750@github.com>

On Thu, 12 Sep 2024 12:01:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Yes, it could, but the problem is that in this way the precondition `(resPos <= offset || resPos >= offset + intLen)` would be no longer correct, and in particular `resPos <= offset` is used by `MBI.leftShift()` if `result == value`.
>
> I mean something like
> 
>     private void primitiveRightShift(int n, int[] result, int resPos) {
>         int[] val = value;
>         int n2 = 32 - n;
>         int c = 0;
>         for (int i = 0; i < intLen; i++) {
>             int b = val[offset + i];
>             result[resPos + i] = c << n2 | b >>> n;
>             c = b;
>         }
>     }
> 
> and
> 
>     private void primitiveLeftShift(int n, int[] result, int resPos) {
>         int[] val = value;
>         int n2 = 32 - n;
>         int c = 0;
>         for (int i = intLen - 1; i >= 0; i--) {
>             int b = val[offset + i];
>             result[resPos + i] = c >>> n2 | b << n;
>             c = b;
>         }
> 
> They are compatible with the precondition, right?

But in the second version, the precondition must be `resPos <= offset - intLen || resPos >= offset` to make sure that the result is correct whether `result == value`, and the condition `resPos <= offset - intLen` is stronger than `resPos <= offset`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756759551

From pminborg at openjdk.org  Thu Sep 12 12:44:41 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 12:44:41 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths [v2]
In-Reply-To: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
Message-ID: <R7BBNrbnkpWXPRSUp-QvxPYGTFqqKh5SKHBHdlq1wrk=.b040a4f3-979a-4af1-ba27-a3a7dd2c8244@github.com>

> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.

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 10 additional commits since the last revision:

 - Remove trailing blanks
 - Add back extra line break
 - Add copyright year
 - Update copyright year
 - Revoke change to copyright year
 - Reinstate code
 - Move logic to doc
 - Merge branch 'master' into ms-string-known-length
 - Add copyright year
 - Add MemorySegment::getString overload

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20725/files
  - new: https://git.openjdk.org/jdk/pull/20725/files/8fb0e616..cc862a05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20725&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20725&range=00-01

  Stats: 23542 lines in 797 files changed: 14212 ins; 4981 del; 4349 mod
  Patch: https://git.openjdk.org/jdk/pull/20725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20725/head:pull/20725

PR: https://git.openjdk.org/jdk/pull/20725

From duke at openjdk.org  Thu Sep 12 12:45:06 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 12:45:06 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v7]
In-Reply-To: <K2itlbEquuFGrRMCCGVF3ONFS4Om5G1DOy81J_paYyo=.8d400645-afca-40a3-887c-229a6335f667@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <TcrTHm2Kpt0iUO_S79PiKm0pJWU2r8e4SZXPUKEw6wQ=.aebc56c8-2a43-4c83-b634-7aa6d49f07e3@github.com>
 <oKHvXZbzvZxyFDPmu8Zm45kcP8rtuv3s4MY3zcn9EUI=.771dde83-de60-4b57-91d1-ab51bb550011@github.com>
 <-WIdjPSD9QFIQ1VLQG38taoRpvfrj2PyIxYcc5pAteQ=.495826f4-4a42-4960-ac1b-3fa5fff5887a@github.com>
 <c0329jZF4HvMc4aHMw5Dg3OyK0S2cVyIIMJaEGrCDBw=.cbdccfa9-414b-4baf-995f-e3e6973adea7@github.com>
 <cjZmTWkShwaYPsn5ou2kQ1OeU3fHAI3cMXWjVR66V9E=.c62c82ec-2ec5-4639-8e3b-f1ea6d4f139a@github.com>
 <6iHzs6cZovf6Rg3xej1GZ8Y0X7WobJwwbL0_9N7bSZI=.fbcbd2ee-3a67-4bfd-9e85-a68b5ea8397b@github.com>
 <K2itlbEquuFGrRMCCGVF3ONFS4Om5G1DOy81J_paYyo=.8d400645-afca-40a3-887c-229a6335f667@github.com>
Message-ID: <v9idpi79IoWzE9NVWmLTTP3eAV7YyBHIGIPyIdKlQ68=.ddf05875-6171-4d3e-acfe-8806099cfbb6@github.com>

On Thu, 12 Sep 2024 12:21:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> So, a test should be done for every possible path of computation of `MBI.leftShift()` method...
>
> Looking at the code of `leftShift()` alone, I roughly count a dozen or so paths.
> But if you feel confident that the random tests cover all paths over several executions with high probability and that no corner cases are left out, then they might suffice.

I think that specific test cases for every path would make the code more reliable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756784216

From pminborg at openjdk.org  Thu Sep 12 12:51:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 12:51:05 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v12]
In-Reply-To: <u2Ni-W-OPwVgDma7pxmP1nERla0ZfQzOufn_n0aqdbY=.dc8b40f6-516b-4072-a751-051afb2c20e9@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <cbQUD8ryQiTLBQOASciyxz2PIeXmHiwY0ZM1co3YmUI=.6ed5f4c8-fc37-4af0-9d59-a83b2ea22a01@github.com>
 <b6YpYZuRdn6Kv2oDSPkb2S33S3rEXVOBJTt0wCejerk=.2c89b6bf-f6b4-434f-9d67-3439bd763b4c@github.com>
 <kVgsp4VBzxe0g3udZrNkdqOujJghiig0Q49EmDPIN-U=.c0fbcbfa-e789-456a-b60d-408c376f0e62@github.com>
 <u2Ni-W-OPwVgDma7pxmP1nERla0ZfQzOufn_n0aqdbY=.dc8b40f6-516b-4072-a751-051afb2c20e9@github.com>
Message-ID: <KzAZ-PPcRe_8gwEX6EFa_ooDcgkx1XQH3dagW2l-GWU=.887c4b8e-3edf-4ff4-8b82-84c7acbe6feb@github.com>

On Thu, 12 Sep 2024 11:34:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> In other words, I don't think the goal of this (and related) PR is "improve mismatch so that it blows other alternatives - like Unsafe, or array" out of the water - as much as it is "make sure that using MemorySegment::mismatch is competitive with other offerings".
>
> Then, an interesting part of these PRs is that we have uncovered quite a lot of issues both with our intrinsics (e.g. `fill` is not vectorized and works badly on Windows, mismatch works poorly on aarch64) *and* missed optimization opportunities - e.g. "short" segment loops are not optimized as tightly as they could. But it is not the job of these PRs to fix all these issues. The main focus remain: for small sizes it is not worth going down intrinsics-lane. Let's stick to it (in the interest of keeping the review focused).

Yepp. So, let us keep these tricks up our sleeves and then maybe come back with a new PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1756793795

From pminborg at openjdk.org  Thu Sep 12 13:06:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 13:06:47 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v13]
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <VxyODGsiotqkbKoLfTE2gV7IzWUgp9_ZHsBY5zqcj0g=.80d87d9f-81f3-463d-83a4-ff05a9494d61@github.com>

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert unrolling changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20848/files
  - new: https://git.openjdk.org/jdk/pull/20848/files/e93d334a..39bd4734

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20848&range=11-12

  Stats: 43 lines in 1 file changed: 0 ins; 36 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20848/head:pull/20848

PR: https://git.openjdk.org/jdk/pull/20848

From redestad at openjdk.org  Thu Sep 12 13:10:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Sep 2024 13:10:08 GMT
Subject: RFR: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry [v5]
In-Reply-To: <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
 <v26Z1vWw18Gz6MN_hSeys6oYaSRD4boj0-MovCkprSo=.2435750b-f5fd-4c33-a72a-3e11e5880ab3@github.com>
Message-ID: <Vt-QUYqa-mcDB7cOWoBqUjdS42RPLyRExHI8YeeAQGU=.96ccdff1-9ff1-41e8-a7ea-f7050e654ee0@github.com>

On Thu, 12 Sep 2024 11:28:20 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
>> 
>> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
>> 
>> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
>> 
>> Since `ZipFile.getZipEntry` now has the name, CEN header fields can now be read in bulk, separate from the allocation of the `ZipEntry`. This reordering is unlocked by the other changes in this PR and can alone explain a lot of the performance gains, probably because of better cache use.
>> 
>> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
>> 
>> Baseline:
>> 
>> 
>> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
>> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
>> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
>> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
>> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
>> 
>> The changes in this PR makes `UTF8ZipCoder.compare` the only caller of `ZipCoder.hasTrailingSlash`, so this method is made private and the implementation in the base class retired.
>> 
>> This purely a cleanup and optimization PR, no functional tests are changed or added.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment where getEntry calls Source::getEntryPos

LGTM

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20939#pullrequestreview-2300253644

From rgiulietti at openjdk.org  Thu Sep 12 13:26:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Sep 2024 13:26:06 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v9]
In-Reply-To: <ie7d3NC-zvF004fnO5L2xhA1DnGtiaAqcfp1OwY3gPQ=.f2aa1d2f-b5a8-4ac3-a393-f5426c07d750@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <P0HNsXo-2rz-04h0K-oZKah6QG2YKD3ECvO3tGrGCpM=.16150db9-9c76-4422-95ba-040bc4da24fb@github.com>
 <KabfYZr6WUocqsVpAcPxurIasQIxobg-SLL4VLvKllw=.fcd5c56f-411d-454d-9f3f-f92717f687d8@github.com>
 <lElKq6b7opPtdriovm6nnNIIGxkjzS6-vhN49O_Cz0Y=.a4a0ea98-2c67-437f-a5cc-50142416b1ae@github.com>
 <JMU9vClq0rI6UadJgOECSNRYZMD6YCw4ZSK8Hm7czwA=.3ca85dbd-c816-41c0-9588-8c6f6f82717c@github.com>
 <ie7d3NC-zvF004fnO5L2xhA1DnGtiaAqcfp1OwY3gPQ=.f2aa1d2f-b5a8-4ac3-a393-f5426c07d750@github.com>
Message-ID: <DwzjLlldPdqf_wgGwi2CIz1-KGKcTG1vk0ZMsEAmhzA=.7a1dd658-8bdb-4438-b958-ae8f5e0de2d5@github.com>

On Thu, 12 Sep 2024 12:27:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I mean something like
>> 
>>     private void primitiveRightShift(int n, int[] result, int resPos) {
>>         int[] val = value;
>>         int n2 = 32 - n;
>>         int c = 0;
>>         for (int i = 0; i < intLen; i++) {
>>             int b = val[offset + i];
>>             result[resPos + i] = c << n2 | b >>> n;
>>             c = b;
>>         }
>>     }
>> 
>> and
>> 
>>     private void primitiveLeftShift(int n, int[] result, int resPos) {
>>         int[] val = value;
>>         int n2 = 32 - n;
>>         int c = 0;
>>         for (int i = intLen - 1; i >= 0; i--) {
>>             int b = val[offset + i];
>>             result[resPos + i] = c >>> n2 | b << n;
>>             c = b;
>>         }
>> 
>> They are compatible with the precondition, right?
>
> But in the second version, the precondition must be `resPos <= offset - intLen || resPos >= offset` to make sure that the result is correct whether `result == value`, and the condition `resPos <= offset - intLen` is stronger than `resPos <= offset`.

Yes, I agree.

This one should correctly account for the precondition, and IMO is slightly simpler to read.

    private void primitiveLeftShift(int n, int[] result, int resPos) {
        int[] val = value;
        int n2 = 32 - n;
        final int m = intLen - 1;
        int b = val[offset];
        for (int i = 0; i < m; i++) {
            int c = val[offset + i + 1];
            result[resPos + i] = (b << n) | (c >>> n2);
            b = c;
        }
        result[resPos + m] = b << n;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1756855722

From redestad at openjdk.org  Thu Sep 12 13:33:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Sep 2024 13:33:12 GMT
Subject: RFR: 8340011: Simplify jdk.internal.classfile.impl.EntryMap
Message-ID: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>

Minor refactoring to avoid the need to define two anonymous classes that override `EntryMap`. Minor speed-up in interpreter, as well.

-------------

Commit messages:
 - Simplify jdk.internal.classfile.impl.EntryMap

Changes: https://git.openjdk.org/jdk/pull/20966/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20966&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340011
  Stats: 49 lines in 2 files changed: 0 ins; 15 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/20966.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20966/head:pull/20966

PR: https://git.openjdk.org/jdk/pull/20966

From liach at openjdk.org  Thu Sep 12 13:33:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Sep 2024 13:33:13 GMT
Subject: RFR: 8340011: Simplify jdk.internal.classfile.impl.EntryMap
In-Reply-To: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>
References: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>
Message-ID: <g9j3N8yUmiahZcNTReG977qmVqqTfANnap1qP9hKZDA=.ce8026bf-c5da-4cf4-bce4-6b6f24241afb@github.com>

On Thu, 12 Sep 2024 13:26:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Minor refactoring to avoid the need to define two anonymous classes that override `EntryMap`. Minor speed-up in interpreter, as well.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20966#pullrequestreview-2300320268

From mcimadamore at openjdk.org  Thu Sep 12 13:48:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Sep 2024 13:48:08 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths [v2]
In-Reply-To: <R7BBNrbnkpWXPRSUp-QvxPYGTFqqKh5SKHBHdlq1wrk=.b040a4f3-979a-4af1-ba27-a3a7dd2c8244@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <R7BBNrbnkpWXPRSUp-QvxPYGTFqqKh5SKHBHdlq1wrk=.b040a4f3-979a-4af1-ba27-a3a7dd2c8244@github.com>
Message-ID: <9bcdMa-g1nzX5LyOWDtMnsQDyH3MMPjgMA0OjOP6hpw=.bff9c289-eb87-4c92-a9fa-031cb8b93f32@github.com>

On Thu, 12 Sep 2024 12:44:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.
>
> 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 10 additional commits since the last revision:
> 
>  - Remove trailing blanks
>  - Add back extra line break
>  - Add copyright year
>  - Update copyright year
>  - Revoke change to copyright year
>  - Reinstate code
>  - Move logic to doc
>  - Merge branch 'master' into ms-string-known-length
>  - Add copyright year
>  - Add MemorySegment::getString overload

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1288:

> 1286:      * over the decoding process is required.
> 1287:      * <p>
> 1288:      * Getting a String from a {@code segment} with a known byte {@code offset} and

Suggestion:

     * Getting a string from a {@code segment} with a known byte {@code offset} and

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1756905874

From mcimadamore at openjdk.org  Thu Sep 12 13:48:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Sep 2024 13:48:08 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths [v2]
In-Reply-To: <9bcdMa-g1nzX5LyOWDtMnsQDyH3MMPjgMA0OjOP6hpw=.bff9c289-eb87-4c92-a9fa-031cb8b93f32@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <R7BBNrbnkpWXPRSUp-QvxPYGTFqqKh5SKHBHdlq1wrk=.b040a4f3-979a-4af1-ba27-a3a7dd2c8244@github.com>
 <9bcdMa-g1nzX5LyOWDtMnsQDyH3MMPjgMA0OjOP6hpw=.bff9c289-eb87-4c92-a9fa-031cb8b93f32@github.com>
Message-ID: <hXzGsQjUT7Q2DZ9e36bXJS5DUFcpTosxPWqvQaDcb4U=.949c029c-d724-4f6f-8dad-19acb1148268@github.com>

On Thu, 12 Sep 2024 13:44:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Remove trailing blanks
>>  - Add back extra line break
>>  - Add copyright year
>>  - Update copyright year
>>  - Revoke change to copyright year
>>  - Reinstate code
>>  - Move logic to doc
>>  - Merge branch 'master' into ms-string-known-length
>>  - Add copyright year
>>  - Add MemorySegment::getString overload
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1288:
> 
>> 1286:      * over the decoding process is required.
>> 1287:      * <p>
>> 1288:      * Getting a String from a {@code segment} with a known byte {@code offset} and
> 
> Suggestion:
> 
>      * Getting a string from a {@code segment} with a known byte {@code offset} and

I would drop all the `{@code ... }` here. E.g. 

Getting a string from a segment with known byte offset and byte length can be done like so:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1756907925

From mcimadamore at openjdk.org  Thu Sep 12 13:50:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Sep 2024 13:50:06 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v13]
In-Reply-To: <VxyODGsiotqkbKoLfTE2gV7IzWUgp9_ZHsBY5zqcj0g=.80d87d9f-81f3-463d-83a4-ff05a9494d61@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <VxyODGsiotqkbKoLfTE2gV7IzWUgp9_ZHsBY5zqcj0g=.80d87d9f-81f3-463d-83a4-ff05a9494d61@github.com>
Message-ID: <UBtGVjCKRRHG-_k5Zxs4s49DRCXua9m1Q-5fMM6zssc=.e43ce1e3-228f-4206-a005-884a901a187d@github.com>

On Thu, 12 Sep 2024 13:06:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unrolling changes

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20848#pullrequestreview-2300380963

From duke at openjdk.org  Thu Sep 12 14:06:53 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 14:06:53 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v10]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <6Sudc32fLl1Xs64Xg6343miQqVjKZZxFh5_S0D7Urp4=.1f7c62cc-b999-4d3c-8e9f-9ab0cab60d9e@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Some code clarifications

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/daa2d157..f89b7ab9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=08-09

  Stats: 13 lines in 2 files changed: 1 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From redestad at openjdk.org  Thu Sep 12 15:11:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Sep 2024 15:11:08 GMT
Subject: Integrated: 8340011: Simplify jdk.internal.classfile.impl.EntryMap
In-Reply-To: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>
References: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>
Message-ID: <2Xxspv5zdfyHeAKS1bBWM2PtTFtYBtEs1VT8MhPFKcA=.00fe1d95-71af-4777-95b0-2f7074ee1121@github.com>

On Thu, 12 Sep 2024 13:26:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Minor refactoring to avoid the need to define two anonymous classes that override `EntryMap`. Minor speed-up in interpreter, as well.

This pull request has now been integrated.

Changeset: 0765917d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0765917dea9376586697012b60605099750d8d42
Stats:     49 lines in 2 files changed: 0 ins; 15 del; 34 mod

8340011: Simplify jdk.internal.classfile.impl.EntryMap

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20966

From redestad at openjdk.org  Thu Sep 12 15:11:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Sep 2024 15:11:08 GMT
Subject: RFR: 8340011: Simplify jdk.internal.classfile.impl.EntryMap
In-Reply-To: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>
References: <g9ojJZ7i4xuc1qCbr_ESmIb6CvUNJQipKB77qJ6TMhs=.0f712e88-b67d-41a6-9063-39ae2185a538@github.com>
Message-ID: <radZ_1VCGqBRxxp_MbhSuU0cEpZIxA_-lBd6LuQ201Q=.411d662b-c070-486d-90ba-45b0b47ce959@github.com>

On Thu, 12 Sep 2024 13:26:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Minor refactoring to avoid the need to define two anonymous classes that override `EntryMap`. Minor speed-up in interpreter, as well.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20966#issuecomment-2346561354

From liach at openjdk.org  Thu Sep 12 15:19:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Sep 2024 15:19:08 GMT
Subject: Integrated: 8339876: Move constant symbol caches to Utf8EntryImpl
In-Reply-To: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
References: <m9pOoVY-DjYUV7z2g0oUAvvt4zQiUTK4a_KrzL3Hr4Y=.c71ef8ba-976c-419f-b0b2-8ed9449a5228@github.com>
Message-ID: <Wz9BpWuwj6nzli6vK1JbzCsWgOaoGgVHOn3s0fsBQ2I=.a290ded1-4f6b-40db-8d7e-c3adcd965595@github.com>

On Wed, 11 Sep 2024 23:31:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some type descriptors are validated against generic utf8 entries, such as field or method types; we can cache a type descriptor wrapping the content of the utf8 entry if this entry is ever used as a type descriptor.
> 
> This patch is more of a code cleanup; it is performance neutral.

This pull request has now been integrated.

Changeset: 4d65c3ef
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d65c3efcaa5f855f9e0fbdd8e9d4f4ed2b44d3b
Stats:     169 lines in 19 files changed: 56 ins; 82 del; 31 mod

8339876: Move constant symbol caches to Utf8EntryImpl

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20957

From eirbjo at openjdk.org  Thu Sep 12 15:27:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 12 Sep 2024 15:27:12 GMT
Subject: Integrated: 8339874: Avoid duplicate checking of trailing slash in
 ZipFile.getZipEntry
In-Reply-To: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
References: <thSaE9xDxiTpBUmJKn98lFnDQSI6AUXRPE6IDRb8u7U=.30bcdeec-718f-4ee6-a195-a173f5a558c2@github.com>
Message-ID: <xZ-QrH3SCvbcU7MwD89auFp_gzJoIrAMFc2lRmizubQ=.c9e16a44-62c7-4fc1-8e46-da8cdb34427f@github.com>

On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `ZipFile.getZipEntry` by removing slash-checking logic which is already taking place during lookup in `ZipFile.Source.getEntryPos`. 
> 
> `ZipFile.Source.getEntryPos` includes logic to match a lookup for "name" against a directory entry "name/" (with a trailing slash). However, only the CEN position is currently returned, so `ZipFile.getZipEntry` needs to re-read the name from the CEN and determine if a trailing slash needs to be appended to the name of the returned `ZipEntry`.
> 
> By letting `ZipFile.Source.getEntryPos` return the resolved name along with the CEN position (in a new record `EntryPos`), `ZipFile.getZipEntry` can now instead use the already resolved name. 
> 
> Since `ZipFile.getZipEntry` now has the name, CEN header fields can now be read in bulk, separate from the allocation of the `ZipEntry`. This reordering is unlocked by the other changes in this PR and can alone explain a lot of the performance gains, probably because of better cache use.
> 
> This results in a nice ~18% speedup in the `ZipFileGetEntry.getEntryHit` micro:
> 
> Baseline:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  63.713 ? 2.645  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  67.405 ? 1.474  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                    (size)  Mode  Cnt   Score   Error  Units
> ZipFileGetEntry.getEntryHit     512  avgt   15  52.027 ? 2.669  ns/op
> ZipFileGetEntry.getEntryHit    1024  avgt   15  55.211 ? 1.169  ns/op
> 
> The changes in this PR makes `UTF8ZipCoder.compare` the only caller of `ZipCoder.hasTrailingSlash`, so this method is made private and the implementation in the base class retired.
> 
> This purely a cleanup and optimization PR, no functional tests are changed or added.

This pull request has now been integrated.

Changeset: 7f1dae12
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f1dae12e5e24d204a70cf610a8c482996556931
Stats:     79 lines in 2 files changed: 16 ins; 45 del; 18 mod

8339874: Avoid duplicate checking of trailing slash in ZipFile.getZipEntry

Reviewed-by: lancea, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20939

From bpb at openjdk.org  Thu Sep 12 15:43:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 15:43:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
Message-ID: <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>

On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Thanks for making the changes. LGTM, assuming that tests still pass.

The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating.

> src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221:
> 
>> 219: static futimesat_func* my_futimesat_func = NULL;
>> 220: static futimens_func* my_futimens_func = NULL;
>> 221: #ifndef _ALLBSD_SOURCE
> 
> This change looks unrelated. Was it intentional?

Yes. The variable on the next line `my_lutimes_func` caused an unused variable error in the macOS build.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346633671
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757123250

From bpb at openjdk.org  Thu Sep 12 15:43:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 15:43:13 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
Message-ID: <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>

On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit.
>
> Moved to `NTLMAuthentication` static initializer. 853d349

@dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757130549

From alanb at openjdk.org  Thu Sep 12 15:46:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Sep 2024 15:46:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
 <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>
Message-ID: <bR_LAEbbJNy6uwRvxYcyM3Q_yF8nPyAOd76OPZPb-EE=.068b1001-f855-4a6c-bf32-51a28088dc29@github.com>

On Thu, 12 Sep 2024 15:38:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating.

Can you hold off integrating, I plan to go over the changes soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346644977

From bpb at openjdk.org  Thu Sep 12 15:51:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 15:51:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <bR_LAEbbJNy6uwRvxYcyM3Q_yF8nPyAOd76OPZPb-EE=.068b1001-f855-4a6c-bf32-51a28088dc29@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
 <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>
 <bR_LAEbbJNy6uwRvxYcyM3Q_yF8nPyAOd76OPZPb-EE=.068b1001-f855-4a6c-bf32-51a28088dc29@github.com>
Message-ID: <i2i7oyoiicpHXF16NDxjZ5utlPCc3IZSzXv8BeUZ5bs=.dec7a08c-48de-4d35-ba37-7847901a6964@github.com>

On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you hold off integrating, I plan to go over the changes soon.

I don't plan to integrate until you have reviewed it. I set the minimum reviewer count to 3 to avoid doing so accidentally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346655197

From sgehwolf at openjdk.org  Thu Sep 12 15:51:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 12 Sep 2024 15:51:11 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v8]
In-Reply-To: <UTnnI1alBcxtGobkQuwiqk5uBi1wf6So9NKkIp58GqA=.0a1a1060-dd97-4a11-86bf-705ea8169ed2@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <UTnnI1alBcxtGobkQuwiqk5uBi1wf6So9NKkIp58GqA=.0a1a1060-dd97-4a11-86bf-705ea8169ed2@github.com>
Message-ID: <kTo9LCdkcmLx-vQ9arHmKo36cK-Wu2OKASjaKCalLtQ=.1ee68ce1-d4d7-4922-85c7-77c21e20e61c@github.com>

On Wed, 11 Sep 2024 17:52:44 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 32 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Improve systemd slice test for non-root on cg v2
>  - Fix unit tests
>  - Add JVM_HostActiveProcessorCount using JVM api
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - Adjust test and fix code to return lowest hierarchical limit
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/d9fdf69c...0f559199

Anyone willing to review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2346655808

From asemenyuk at openjdk.org  Thu Sep 12 16:19:22 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Sep 2024 16:19:22 GMT
Subject: RFR: 8334301: Errors in jpackage man page
Message-ID: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>

Correct jpackage man errors

-------------

Commit messages:
 - JDK-8334301: Errors in jpackage man page

Changes: https://git.openjdk.org/jdk/pull/20969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20969&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334301
  Stats: 24 lines in 1 file changed: 10 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20969/head:pull/20969

PR: https://git.openjdk.org/jdk/pull/20969

From asemenyuk at openjdk.org  Thu Sep 12 16:19:22 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Sep 2024 16:19:22 GMT
Subject: RFR: 8334301: Errors in jpackage man page
In-Reply-To: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>
References: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>
Message-ID: <vELe8uDmkLwF7HxmPHuPK6OuO7CrVqOzCLtxRBgZkLM=.b456d25f-a9bb-4c32-8b8d-a36ff6ac6934@github.com>

On Thu, 12 Sep 2024 16:14:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Correct jpackage man errors

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20969#issuecomment-2346723922

From dev at anthonyv.be  Thu Sep 12 17:54:53 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Thu, 12 Sep 2024 17:54:53 +0000
Subject: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>

Hi Viktor

September 8, 2024 at 5:20 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >The non-reusability is intentional here, being a drop-in replacement for `Stream::concat`.
> 
> Gatherers are designed to be reusable, Streams not. So having a Gatherer which isn't reusable would be a bit of a non-starter I'm afraid. Or perhaps I misunderstood?

While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?

For concatenation, I'd expect a `Gatherer append(T...)` to be reusable.
But I'd find it equally intuitive for a `Gatherer concat(Stream<T>)` not to be reusable, since its argument might be an infinite Stream.
In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.

As another example, take Gunnar Morling's zip Gatherers: https://github.com/gunnarmorling/zip-gatherer
I don't see how Gatherers like this could be made reusable, or why that would even be desirable.

> Personally, when I want to concat multiple streams of the same type I do:
> 
> Stream.of(foo, bar).flatMap(identity).filter(?).map(?).toList();

Yes, this is the idiom mentioned by `Stream::concat`, but your `foo` is not equivalent to the one in my e-mail.
My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
Currently we have to extract a variable for the first part of the pipeline and then use either `Stream::concat` or the above idiom to maintain readability.
With a `concat` Gatherer, the pipeline could be written as one fluent chain of method invocations.

Kind regards, Anthony

> Cheers,
> 
> ?
> 
> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle
> 
> ????????????????????????????????????????????????????????????????
> 
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Saturday, 7 September 2024 21:03
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** Re: [External] : Re: Stream Gatherers (JEP 473) feedback
> ?
> 
> September 2, 2024 at 10:36 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> > 
> 
> > Hi Anthony,
> 
> Hi Viktor
> 
> > Thank you for your patience, I needed some time to experiment and think about your feedback.
> 
> > 
> 
> > >* how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?
> 
> > 
> 
> > If looking at the past to inform extrapolation into the future, then the trend is going in the direction of improving over time.
> 
> > 
> 
> > >Gatherers.identity()
> 
> > 
> 
> > I still need some time to experiment with this, as there are some implications.
> 
> > For instance, if you do: **Steam.of(1).gather(Gatherers.identity()) **you'd want that gatherer to be dropped since it is a no-op, but you can't really do that without breaking the contract of Stream.gather, as that operation should "consume" the original Stream reference and return a new one (to preserve stream building linearity), so you'd still need to create a new ReferencePipeline instance which is a copy of the current one, and mark the previous as consumed)?in essence Stream.gather(identity) wouldn't be a no-op.
> 
> > 
> 
> > There are some other, performance-related, things I'll need to verify as well before coming to any conclusion on this.
> 
> > 
> 
> > >Gatherers.concat(Stream<T> stream)
> 
> The non-reusability is intentional here, being a drop-in replacement for `Stream::concat`.
> 
> (In what follows, assume the ellipses are method references, and the pipelines are nicely formatted and perfectly readable.)
> 
> The idea is to be able to write pipelines of the form:
> 
> var list = foo.filter(...).map(...).flatMap(...).concat(bar).map(...).filter(...).gather(...).toList();
> 
> Currently you have to write such pipelines as:
> 
> var list = Stream.concat(foo.filter(...).map(...).flatMap(...), bar).map(...).filter(...).gather(...).toList();
> 
> or:
> 
> var head = foo.filter(...).map(...).flatMap(...);
> 
> var concatenated = Stream.concat(head, bar);
> 
> var list = concatenated.map(...).filter(...).gather(...).toList();
> 
> But now you could write them as follows and retain a single, fluent pipeline:
> 
> var list = foo.filter(...).map(...).flatMap(...).gather(concat(bar)).map(...).filter(...).gather(...).toList();
> 
> My argument for including it would be that the above use case is common enough. `Stream::concat` could then also reference it in its Javadoc as an alternative.
> 
> > Creating such a Gatherer means that it is not reusable. You'd need to have a Supplier<Stream<T>>. Otherwise this happens:
> 
> > 
> 
> > jshell> ? ? public static?<T> Gatherer<T, ?, T> **concat**(Stream<T>**newStream**) {
> 
> > ?? ...> ? ? ? ? return?Gatherer.of(
> 
> > ?? ...> ? ? ? ? ? ? ? ? Gatherer.Integrator.ofGreedy((_, **e**, **d**) -> d.push(e)),
> 
> > ?? ...> ? ? ? ? ? ? ? ? (_, **d**) -> newStream.sequential().allMatch(d::push)
> 
> > ?? ...> ? ? ? ? );
> 
> > ?? ...> ? ? }
> 
> > ?? ...>?
> 
> > |? created method concat(Stream<T>)
> 
> > 
> 
> > jshell> var **inject**?= concat(Stream.of(1,2))
> 
> > inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000db898 at 1068e947]
> 
> > 
> 
> > jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
> 
> > |? Exception java.lang.IllegalStateException: stream has already been operated upon or closed
> 
> > |? ? ? ? at AbstractPipeline.evaluate (AbstractPipeline.java:260)
> 
> > |? ? ? ? at ReferencePipeline.allMatch (ReferencePipeline.java:677)
> 
> > |? ? ? ? at lambda$concat$1 (#4:4)
> 
> > |? ? ? ? at Gatherers$Composite.lambda$impl$3 (Gatherers.java:611)
> 
> > |? ? ? ? at GathererOp$GatherSink.end (GathererOp.java:181)
> 
> > |? ? ? ? at AbstractPipeline.copyInto (AbstractPipeline.java:571)
> 
> > |? ? ? ? at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
> 
> > |? ? ? ? at AbstractPipeline.evaluate (AbstractPipeline.java:636)
> 
> > |? ? ? ? at AbstractPipeline.evaluateToArrayNode (AbstractPipeline.java:291)
> 
> > |? ? ? ? at ReferencePipeline.toArray (ReferencePipeline.java:656)
> 
> > |? ? ? ? at ReferencePipeline.toArray (ReferencePipeline.java:662)
> 
> > |? ? ? ? at ReferencePipeline.toList (ReferencePipeline.java:667)
> 
> > |? ? ? ? at (#6:1)
> 
> > 
> 
> > That being said, given how little code it takes to implement something like that, I am not sure it warrants inclusion:
> 
> > jshell> ? ? public static?<T> Gatherer<T, ?, T> **concat**(Supplier<?extends?Stream<T>> **newStream**) {
> 
> > ?? ...> ? ? ? ? return?Gatherer.of(
> 
> > ?? ...> ? ? ? ? ? ? ? ? Gatherer.Integrator.ofGreedy((**_**, **e**, **d**) -> d.push(e)),
> 
> > ?? ...> ? ? ? ? ? ? ? ? (**_**, **d**) -> newStream.get().sequential().allMatch(d::push)
> 
> > ?? ...> ? ? ? ? );
> 
> > ?? ...> ? ? }
> 
> > |? created method concat(Supplier<? extends Stream<T>>)
> 
> > 
> 
> > jshell> var **inject**?= concat(() -> Stream.of(1,2))
> 
> > inject ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 00001c00000d9c70 at 1a052a00]
> 
> > 
> 
> > jshell> Stream.of(0).gather(inject.andThen(inject)).toList()
> 
> > $1 ==> [0, 1, 2, 1, 2]
> 
> > 
> 
> > Cheers,
> 
> > 
> 
> > ?
> 
> > 
> 
> > **Viktor Klang**
> 
> > Software Architect, Java Platform Group
> 
> > 
> 
> > Oracle
> 
> Kind regards,
> 
> Anthony
> 
> > ????????????????????????????????????????????????????????????????
> 
> > 
> 
> > **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > **Sent:**?Monday, 19 August 2024 20:37
> 
> > **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > **Subject:**?Re: [External] : Re: Stream Gatherers (JEP 473) feedback
> 
> > ?
> 
> > 
> 
> > August 15, 2024 at 1:27 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > Hi Anthony,
> 
> > 
> 
> > Hi Viktor
> 
> > 
> 
> > > Thanks for the input?it's much appreciated!
> 
> > 
> 
> > >
> 
> > 
> 
> > > Introducing yet another, user-facing, type parameter to get slightly improved type inference is unfortunately for me a too high of a price to pay. Ideally, type inference/unification will be improved over time making this issue go away without impacting any signatures.
> 
> > 
> 
> > My arguments would be:
> 
> > 
> 
> > * the type parameter enables using subtypes of Downstream, e.g. `Gatherer::integrator` could return an `Integrator<A, T, R, SpecialDownstream<R>>`
> 
> > 
> 
> > * the type parameter improves type inference
> 
> > 
> 
> > * the type parameter would increase usability. In my experience, nearly all Gatherers are created through the factory methods in Gatherer. And thanks to the improved type inference, I assert that all factory method invocations would work without any type arguments at all. Nowadays type inference is so good that I found it remarkable how often (relatively speaking) I need to provide type arguments with Gatherers, compared to other generic APIs. A substantial amount of Java developers has probably never even had to provide type arguments before, so being able to eliminate their need from the Gatherers API as well seems like a considerable advantage to me
> 
> > 
> 
> > * how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?
> 
> > 
> 
> > > I'm warming up to the idea of shipping a Gatherers.identity(), and before that happens I would like to see more use-cases where having such a thing would provide a real edge. I can come up with a bunch of synthetic scenarios where it's a win, but it's always better to see app logic numbers.
> 
> > 
> 
> > To summarize previous mails, my arguments are:
> 
> > 
> 
> > * it's a common Gatherer. Gatherers of the form `Gatherer<T, ?, T>` will likely have a degenerate case that is the identity. Some actual factory methods are `append(T... elements)` and `concat(Stream<T> stream)`, `prepend(T... elements)`, and `withInterpolationAt(Set<Instant> instants)`.
> 
> > 
> 
> > * optimization: if a Stream pipeline only contains compositions of `Gatherer.identity()`, the Gatherers can be eliminated entirely from the pipeline and characteristics can be propagated. So for example `list.stream().gather(withInterpolationAt(aSetThatHappensToBeEmpty)).count()` would be optimized to `list.stream().count()` and return instantly. Note that while a homemade implementation could optimize its `andThen` implementation, it wouldn't be able to optimize `Gatherer::andThen` and `Stream::gather`.
> 
> > 
> 
> > * API consistency: there's `Function.identity()`, so why not `Gatherers.identity()` (or `Gatherer.identity()`)? Actually I'd argue this method is more useful for Gatherers, since for Functions, this is often written as `o -> o` instead. For Gatherers there's no alternative like that.
> 
> > 
> 
> > On a final note, in case it hasn't been done yet, I'd like to propose `Gatherers.concat(Stream<T> stream)`. The current `Stream::concat` doesn't allow fluent/readable concatenation of multiple streams.
> 
> > 
> 
> > > Getting rid of the rawtypes in Value could be done, at any point since it isn't exposed to user code. I'll keep this in mind for any upcoming maintenance ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > Keep the feedback coming ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > Cheers,
> 
> > 
> 
> > >
> 
> > 
> 
> > > ?
> 
> > 
> 
> > Kind regards,
> 
> > 
> 
> > Anthony
> 
> > 
> 
> > > **Viktor Klang**
> 
> > 
> 
> > > Software Architect, Java Platform Group
> 
> > 
> 
> > >
> 
> > 
> 
> > > Oracle
> 
> > 
> 
> > >
> 
> > 
> 
> > > ????????????????????????????????????????????????????????????????
> 
> > 
> 
> > >
> 
> > 
> 
> > > **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > 
> 
> > > **Sent:** Tuesday, 13 August 2024 18:32
> 
> > 
> 
> > > **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > 
> 
> > > **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
> 
> > 
> 
> > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > Hi Viktor
> 
> > 
> 
> > >
> 
> > 
> 
> > > Your previous response inspired me to experiment some more with Gatherers
> 
> > 
> 
> > >
> 
> > 
> 
> > > As a result I'd like to make a couple propositions:
> 
> > 
> 
> > >
> 
> > 
> 
> > > * add an additional type parameter.
> 
> > 
> 
> > >
> 
> > 
> 
> > > ? After doing so, type inference no longer needs any assistance:
> 
> > 
> 
> > >
> 
> > 
> 
> > > ? `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
> 
> > 
> 
> > >
> 
> > 
> 
> > > * add an identity Gatherer with an optimized `andThen` implementation
> 
> > 
> 
> > >
> 
> > 
> 
> > > ? as well as an optimization in the default implementation of `Gatherer::andThen`
> 
> > 
> 
> > >
> 
> > 
> 
> > > * eliminate the use of raw types in `Gatherers.Value`
> 
> > 
> 
> > >
> 
> > 
> 
> > > Code that implements these propositions is in this gist: https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVct8oxUqg$
> 
> > 
> 
> > >
> 
> > 
> 
> > > Kind regards,
> 
> > 
> 
> > >
> 
> > 
> 
> > > Anthony
> 
> > 
> 
> > >
> 
> > 
> 
> > > July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Hi Anthony,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVdv0LXetA$
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Cheers,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > **Viktor Klang**
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Software Architect, Java Platform Group
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Oracle
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > ????????????????????????????????????????????????????????????????
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > 
> 
> > >
> 
> > 
> 
> > > > **Sent:**?Tuesday, 30 July 2024 17:20
> 
> > 
> 
> > >
> 
> > 
> 
> > > > **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > 
> 
> > >
> 
> > 
> 
> > > > **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> 
> > 
> 
> > >
> 
> > 
> 
> > > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Hi Anthony,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Hi Viktor
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Thank you for your patience, and for providing feedback, it is always much appreciated.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > >When writing factory methods for Gatherers, there's sometimes a
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > to recognize and eliminate it from the pipeline. One idea is to add
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > but rather adding it in case it was deemed necessary.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Do you have a concrete use-case (code) that you could share?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > >Sometimes a factory method returns a Gatherer that only works correctly
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > if the upstream has certain characteristics, for example
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Spliterator.SORTED or Spliterator.DISTINCT.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Do you have a concrete use-case (code) that you could share?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > >One idea is to add methods
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > implementation would be able to recognize and eliminate these from the
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > pipeline if the upstream already has these characteristics. That way
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > idea is to provide a Gatherer with a way to inspect the upstream
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > characteristics. If the upstream is missing the required
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > characteristic(s), it could then throw an IllegalStateException.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > For a rather long time Gatherer had characteristics, however,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > what I noticed is that given composition of Gatherers what ended up happening
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > almost always was that the combination of characteristics added overhead and devolved into the empty set
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > real fast.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > >The returns clause of Gatherer.Integrator::integrate just states "true
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > if subsequent integration is desired, false if not". In particular, it
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > doesn't document the behavior I'm observing, that returning false also
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > causes downstream to reject any further output elements.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$? ), but this is indeed already fixed in JDK 23-ea.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Cheers,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > **Viktor Klang**
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Software Architect, Java Platform Group
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Oracle
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Kind regards,
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > Anthony
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > ????????????????????????????????????????????????????????????????
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > **Sent:** Saturday, 27 July 2024 08:57
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > **Subject:** Stream Gatherers (JEP 473) feedback
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > When writing factory methods for Gatherers, there's sometimes a
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > to recognize and eliminate it from the pipeline. One idea is to add
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Sometimes a factory method returns a Gatherer that only works correctly
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > if the upstream has certain characteristics, for example
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > implementation would be able to recognize and eliminate these from the
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > pipeline if the upstream already has these characteristics. That way
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > idea is to provide a Gatherer with a way to inspect the upstream
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > characteristics. If the upstream is missing the required
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > characteristic(s), it could then throw an IllegalStateException.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > The returns clause of Gatherer.Integrator::integrate just states "true
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > if subsequent integration is desired, false if not". In particular, it
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > doesn't document the behavior I'm observing, that returning false also
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > causes downstream to reject any further output elements.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > In the Implementation Requirements section of Gatherer, rephrasing
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > "Outputs and state later in the input sequence will be discarded if
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > processing an earlier partition short-circuits." to something like the
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > following would be clearer to me: "As soon as any partition
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > short-circuits, the whole Gatherer short-circuits. The state of other
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > partitions is discarded, i.e. there are no further invocations of the
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > combiner. The finisher is invoked with the short-circuiting partition's
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > state." I wouldn't mention discarding of outputs, since that's implied
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > by the act of short-circuiting.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > > Anthony
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > > >
> 
> > 
> 
> > >
> 
> > 
> 
> > > >
> 
> > 
> 
> > >
> 
> >
>

From pminborg at openjdk.org  Thu Sep 12 18:22:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 18:22:42 GMT
Subject: RFR: 8325949: Create an internal utility method for creating VarHandle
 instances
Message-ID: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>

This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.

While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:

| Class File                                      | Base [Bytes] | Patch [Byte] |
| --------------------------------| ------------- | ------------ |
| FutureTask.class                          |             10255 |           10154 |
| AtomicBoolean.class                   |              5364 |             5161 |
|AtomicMarkableReference.class |              3890 |            3687 |

![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)

The new `MethodHandlesInternal.class` file is of size 2012 bytes.

In total for `java.base` we have:

| Build map "jdk"  | Size [Bytes] |
| ---------------| ------------- |
| Base                 |        5963657 |
| Patch                |        5962751 |
| Delta                 |                906|

For 60 billion instances, this represents 54 TB.

-------------

Commit messages:
 - Fix copyright headers
 - Introduce MethodHandlesInternal

Changes: https://git.openjdk.org/jdk/pull/20972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325949
  Stats: 423 lines in 31 files changed: 109 ins; 202 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From pminborg at openjdk.org  Thu Sep 12 18:34:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 18:34:11 GMT
Subject: Integrated: 8339531: Improve performance of MemorySegment::mismatch
In-Reply-To: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
Message-ID: <_hO98Yw5oU0ukjIqd6WDOCklxFDCANKYThrjoGTO9ww=.10db5d10-77ed-451e-a9a9-1e09b1d57db1@github.com>

On Wed, 4 Sep 2024 09:09:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.

This pull request has now been integrated.

Changeset: 81ff91ef
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81ff91ef27a6a856ae2c453a9a9b8333b91da3ab
Stats:     1098 lines in 9 files changed: 720 ins; 372 del; 6 mod

8339531: Improve performance of MemorySegment::mismatch

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/20848

From rriggs at openjdk.org  Thu Sep 12 19:26:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Sep 2024 19:26:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <C3F9JHtUf3BMCvqDA9SxJiBAXCbH0X3du21nBYUAm6A=.74cc321d-8ac9-4b12-88e0-79d2570831cb@github.com>

On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |             10255 |           10154 |
> | AtomicBoolean.class                   |              5364 |             5161 |
> |AtomicMarkableReference.class |              3890 |            3687 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |        5963657 |
> | Patch                |        5962751 |
> | Delta                 |                906|
> 
> For 60 billion instances, this represents 54 TB.

src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 47:

> 45:     private MethodHandlesInternal() {}
> 46: 
> 47:     public static VarHandle findVarHandleOrThrow(MethodHandles.Lookup lookup, Class<?> recv, String name, Class<?> type) {

The method naming might benefit from being clear that failure is fatal; never call it with arguments that might fail.
Perhaps even throw java.lang.InternalError. ExceptionInInitializerError might be misconstrued as a some kind of race or being called too early.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1757467476

From liach at openjdk.org  Thu Sep 12 19:33:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Sep 2024 19:33:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>

On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |             10255 |           10154 |
> | AtomicBoolean.class                   |              5364 |             5161 |
> |AtomicMarkableReference.class |              3890 |            3687 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |        5963657 |
> | Patch                |        5962751 |
> | Delta                 |                906|
> 
> For 60 billion instances, this represents 54 TB.

I think we can elide the `Lookup` argument to perform a always-full-permission lookup operation to simplify call sequence; or, to elide the `recv` receiver argument as it is almost always `lookup.lookupClass()` (except for a few lazy holders)

src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 1:

> 1: /*

I would argue this is closer to invoke than reflect, so can consider moving to `sun.invoke` or even create a new `jdk.internal.invoke` package.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2347081526
PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1757474972

From dholmes at openjdk.org  Thu Sep 12 20:43:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Sep 2024 20:43:10 GMT
Subject: RFR: 8299419: Thread.sleep(millis) may throw OOME [v3]
In-Reply-To: <2WUJ5P6eH0AB8uInKj7rJd1kaDM3TazLzcl1NlqmYR4=.d6203623-9ca3-4ccf-9608-61ee7f468380@github.com>
References: <zXQ8NxC3dGrmNgzdseHa5bMzhIuDvD1u355EyElihyw=.de03a307-4831-49b6-b81d-adae16d3d744@github.com>
 <2WUJ5P6eH0AB8uInKj7rJd1kaDM3TazLzcl1NlqmYR4=.d6203623-9ca3-4ccf-9608-61ee7f468380@github.com>
Message-ID: <71V6eE1WruxsJVLn3qlROXvldnsAZ5xUaK6jCAb6QlI=.c63a0385-3090-411d-8e0f-ae2efb828c50@github.com>

On Wed, 11 Sep 2024 11:42:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang 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 one new commit since the last revision:
> 
>   Removing ThreadSleepEvent.isTurnedOn from stack trace checks

This change exposed an existing bug in the strace tests with a missing constructor - [JDK-8340072](https://bugs.openjdk.org/browse/JDK-8340072)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20923#issuecomment-2347201093

From duke at openjdk.org  Thu Sep 12 20:49:49 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 12 Sep 2024 20:49:49 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v11]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <Zz3KUZecTtgEfPZPqIPnz-S1E1JqsK3-hMkXLTtLHts=.27ec73b3-9376-41d8-9d6b-d6e2637feba7@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Keep parameters' name consistence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/f89b7ab9..09c13c5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From almatvee at openjdk.org  Thu Sep 12 20:50:06 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 12 Sep 2024 20:50:06 GMT
Subject: RFR: 8334301: Errors in jpackage man page
In-Reply-To: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>
References: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>
Message-ID: <AqcjmqLPmbKDPKz9Nh5SBQoDi3so7V3LVk5KlHHtjxE=.28094023-acab-43a9-9518-3e92bc6917a0@github.com>

On Thu, 12 Sep 2024 16:14:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Correct jpackage man errors

Marked as reviewed by almatvee (Reviewer).

Looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20969#pullrequestreview-2301384752
PR Comment: https://git.openjdk.org/jdk/pull/20969#issuecomment-2347210082

From bpb at openjdk.org  Thu Sep 12 21:08:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 21:08:03 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
Message-ID: <11KXmrX0HsdpBPudlG-8lUWdohcBBLIceatEbwioWaw=.72efee69-d842-43c1-9695-a4ece69316ce@github.com>

On Tue, 10 Sep 2024 16:37:11 GMT, sbgoog <duke at openjdk.org> wrote:

> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

Looks all right.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20938#pullrequestreview-2301418242

From viktor.klang at oracle.com  Thu Sep 12 21:55:47 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 12 Sep 2024 21:55:47 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
Message-ID: <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Anthony

Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.

>While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?

To me, this is governed by the following parts of the Gatherer specification<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html>:

"Each invocation of initializer()<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer()>, integrator()<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator()>, combiner()<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner()>, and finisher()<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher()> must return a semantically identical result."

and

"Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstream Gatherer.Downstream<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html>PREVIEW<https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream> for longer than the invocation duration of the method which they are passed to."

And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.

For Stream, the assumption is that they are NOT reusable at all.
For Gatherer, I think the only reasonable assumption is that they are reusable.

>In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?

Not necessarily, if the factory method consumes the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.

>In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.

There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.

>As another example, take Gunnar Morling's zip Gatherers:
I don't see how Gatherers like this could be made reusable, or why that would even be desirable.

Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().

>My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.

My apologies, I misunderstood. To me, the operation you describe is called `inject`.
Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.

Thanks again for the great questions and conversation, it's valuable!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240912/56e54652/attachment.htm>

From jlu at openjdk.org  Thu Sep 12 22:01:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Sep 2024 22:01:37 GMT
Subject: RFR: 8339769: VM crash during initialization if working directory does
 not exist
Message-ID: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>

Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.

Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 

In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. The expected behavior can be restored by checking if an exception occurred from this call and returning if so.

See _src/java.base/unix/native/libjava/java_props_md.c_ at line 520 for context regarding retrieving the current working directory in `GetJavaProperties(JNIEnv *env)`.

Testing done locally on both platforms.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/20975/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20975&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339769
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20975/head:pull/20975

PR: https://git.openjdk.org/jdk/pull/20975

From naoto at openjdk.org  Thu Sep 12 23:11:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Sep 2024 23:11:14 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ files
Message-ID: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>

Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
...
      The main source files' time zone abbreviations now use %z,
      supported by zic since release 2015f and used in vanguard form
      since release 2022b. For example, America/Sao_Paulo now contains
      the zone continuation line "-3:00 Brazil %z", which is less error
      prone than the old "-3:00 Brazil -03/-02". This does not change
      the represented data: the generated TZif files are unchanged.
      Rearguard form still avoids %z, to support obsolescent parsers.
...

Also fixed the logic to retrieve the linked tz name that is chaining.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/20979/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340073
  Stats: 20 lines in 2 files changed: 12 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20979/head:pull/20979

PR: https://git.openjdk.org/jdk/pull/20979

From jlu at openjdk.org  Thu Sep 12 23:11:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Sep 2024 23:11:31 GMT
Subject: RFR: 8339769: VM crash during initialization if working directory
 does not exist [v2]
In-Reply-To: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
Message-ID: <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>

> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
> 
> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
> 
> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
> 
> 
>     // Get the platform specific values
>     sprops = GetJavaProperties(env);
>     CHECK_NULL_RETURN(sprops, NULL);
> 
> 
> Testing done locally on both platforms.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  return null in exception site instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20975/files
  - new: https://git.openjdk.org/jdk/pull/20975/files/ec2e3030..c69216ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20975&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20975&range=00-01

  Stats: 8 lines in 2 files changed: 3 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20975/head:pull/20975

PR: https://git.openjdk.org/jdk/pull/20975

From sviswanathan at openjdk.org  Thu Sep 12 23:17:13 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 12 Sep 2024 23:17:13 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
Message-ID: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>

Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.

Summary of changes is as follows:
 1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
 2) Intrinsic for wrapIndexes and selectFrom to generate efficient code

For the following source:


    public void test() {
        var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
        for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
            var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
            index.selectFrom(inpvect).intoArray(byteres, j);
        }
    }


The code generated for inner main now looks as follows:
;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
  0x00007f40d02274d0:   movslq %ebx,%r13
  0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
  0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
  0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
  0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
  0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
  0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
  0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
  0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
  0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
  0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
  0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
  0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
  0x00007f40d022751f:   add    $0x40,%ebx
  0x00007f40d0227522:   cmp    %r8d,%ebx
  0x00007f40d0227525:   jl     0x00007f40d02274d0

Best Regards,
Sandhya

-------------

Commit messages:
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into rearrangewrap
 - Some cleanup
 - Some small fixes
 - Initial feedback
 - Optionally partial wrap shuffles during construction
 - Wrap shuffle on rearrange

Changes: https://git.openjdk.org/jdk/pull/20634/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340079
  Stats: 686 lines in 47 files changed: 548 ins; 30 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/20634.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20634/head:pull/20634

PR: https://git.openjdk.org/jdk/pull/20634

From psandoz at openjdk.org  Thu Sep 12 23:17:13 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Sep 2024 23:17:13 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <0LLon0mwzZnp8sR_306z0BoBUjXQAgLBn_KHP-37PC0=.802ff560-b97b-43ba-83b1-94d331d7e03e@github.com>

On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

API shapes are good!

I see you intrinsified `selectFrom` which, IIUC, optimally generates C2 nodes that are functionally equivalent to the Java expression `v.rearrange(this.toShuffle())`. That way we can better generate an optimal set of instructions? 

Do you know what deficiencies there that blocks us from compiling the expression down to the same set of instructions as the intrinsic? Not suggesting we do that here, just for future reference.

Adding link to UTF-8 decoding use case for convenience and reminder: https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.

I think this is good enough to promote out of draft and create a CSR for the API changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2305377165
PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2305412450
PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2346848993

From sviswanathan at openjdk.org  Thu Sep 12 23:17:14 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 12 Sep 2024 23:17:14 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <0LLon0mwzZnp8sR_306z0BoBUjXQAgLBn_KHP-37PC0=.802ff560-b97b-43ba-83b1-94d331d7e03e@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <0LLon0mwzZnp8sR_306z0BoBUjXQAgLBn_KHP-37PC0=.802ff560-b97b-43ba-83b1-94d331d7e03e@github.com>
Message-ID: <ypeW9nEWcZk106SkKSWtHGRRUtLr1AYZS_zgd3Y431k=.10862f72-c39f-494e-acc5-964d2c8a04a7@github.com>

On Thu, 22 Aug 2024 18:21:50 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> API shapes are good!
> 
> I see you intrinsified `selectFrom` which, IIUC, optimally generates C2 nodes that are functionally equivalent to the Java expression `v.rearrange(this.toShuffle())`. That way we can better generate an optimal set of instructions?
> 
> Do you know what deficiencies there that blocks us from compiling the expression down to the same set of instructions as the intrinsic? Not suggesting we do that here, just for future reference.

Yes, I intrinsified to generate optimial set of instructions. In the expression `v.rearrange(this.toShuffle())` we will do first partial wrap as part of this.toShuffle() and then full wrap as part of rearrange. In the intrinsic I am only doing full wrap. Without intrinsic, if for whatever reason the this.toShuffle() is not moved out of the loop by the JIT, we incur additional overhead of the partial wrap in the hot code path.

I saw this happening when the following is run as part of the jmh instead of being called from standalone java with a loop:
        var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
        for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
            var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
            index.selectFrom(inpvect).intoArray(byteres, j);
        }

The perf difference between the intrinsic and no intrinsic observed in this case then is about 20%.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2305521441

From darcy at openjdk.org  Fri Sep 13 02:52:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 02:52:37 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
Message-ID: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>

Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

-------------

Commit messages:
 - JDK-8340082: Use inline return tag in java.base

Changes: https://git.openjdk.org/jdk/pull/20981/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20981&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340082
  Stats: 59 lines in 21 files changed: 0 ins; 27 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/20981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20981/head:pull/20981

PR: https://git.openjdk.org/jdk/pull/20981

From iris at openjdk.org  Fri Sep 13 03:51:03 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Sep 2024 03:51:03 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <wAV473zyPDFQd-ZCIA3dO0mshZj-zXquNxuiswcwvZQ=.e92bc619-7d27-4ede-aa47-a25b5c2cc68a@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302073195

From dholmes at openjdk.org  Fri Sep 13 04:40:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Sep 2024 04:40:08 GMT
Subject: RFR: 8339769: VM crash during initialization if working directory
 does not exist [v2]
In-Reply-To: <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
Message-ID: <AN8YLgMcV4N-bU5U8e4sb3DSnK7S6b1qr-6czoPYPc4=.c645a35c-25f3-49c1-acd4-ac2b4a88bf6f@github.com>

On Thu, 12 Sep 2024 23:11:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return null in exception site instead

Seems like a good fix. This seems to have been working by accident for a long time. IIUC the fix for [JDK-8305746](https://bugs.openjdk.org/browse/JDK-8305746) introduced a Java call that would have encountered this pending exception, but that code then clears any pending exception allowing things to proceed when we failed to setup the encoding properly and so then trigger the unexpected exception.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20975#pullrequestreview-2302107944

From pminborg at openjdk.org  Fri Sep 13 06:31:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 06:31:32 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed: missing
 permission java.lang.foreign.native.threshold.power.fill
Message-ID: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>

This PR fixes a regression introduced by https://github.com/openjdk/jdk/pull/20848

-------------

Commit messages:
 - Use privilegedGetProperty

Changes: https://git.openjdk.org/jdk/pull/20983/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20983&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340081
  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20983/head:pull/20983

PR: https://git.openjdk.org/jdk/pull/20983

From jpai at openjdk.org  Fri Sep 13 06:35:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 06:35:05 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
Message-ID: <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>

On Fri, 13 Sep 2024 06:25:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a regression introduced by https://github.com/openjdk/jdk/pull/20848

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 313:

> 311:     // The returned value is in the interval [0, 2^30]
> 312:     static int powerOfPropertyOr(String name, int defaultPower) {
> 313:         final String property = GetPropertyAction.privilegedGetProperty(PROPERTY_PATH + name);

Hello Per, `sun.security.action.GetIntegerAction.privilegedGetProperty(PROPERTY_PATH + name, defaultPower)` could avoid the null checks and the try blocks here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758259798

From alanb at openjdk.org  Fri Sep 13 06:37:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Sep 2024 06:37:04 GMT
Subject: RFR: 8339769: VM crash during initialization if working directory
 does not exist [v2]
In-Reply-To: <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
Message-ID: <HZ_GJvemFWcpebrsQkqlkykczjku05Mk1UdsID2mv38=.3a4b9081-7e75-4932-bfcb-3243e69a4a74@github.com>

On Thu, 12 Sep 2024 23:11:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return null in exception site instead

The change looks okay, leads to better exception at least. It's a really odd scenario to arise in the first place.

You might want to adjust the JBS/PR title as "VM crash" is a bit mis-leading.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20975#pullrequestreview-2302227712

From dholmes at openjdk.org  Fri Sep 13 06:38:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Sep 2024 06:38:04 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
Message-ID: <P6otZtCM-FhWbzIPtDqv6l4uiG1Vmr8U_ZO3cWxS3_g=.ccd66be4-042c-49e2-ad9f-4c914dad88af@github.com>

On Fri, 13 Sep 2024 06:25:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a regression introduced by https://github.com/openjdk/jdk/pull/20848

LGTM! Thanks for the quick fix.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20983#pullrequestreview-2302228727

From jpai at openjdk.org  Fri Sep 13 06:49:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 06:49:06 GMT
Subject: RFR: 8339769: VM crash during initialization if working directory
 does not exist [v2]
In-Reply-To: <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
Message-ID: <lwAUPuCbA8R2UuUQdRvy49gmduYy5F5KqFdp83xSt4g=.6ffbb66e-5b71-4cda-aa07-a40079167c6d@github.com>

On Thu, 12 Sep 2024 23:11:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return null in exception site instead

Curiously in the Windows implementation of `GetJavaProperties(...)` in `java_props_md.c` in case of a failure to get the current working directory, we seem to just skip setting the working directory and don't raise any error:



/* Current directory */
{
    WCHAR buf[MAX_PATH];
    if (GetCurrentDirectoryW(sizeof(buf)/sizeof(WCHAR), buf) != 0)
        sprops.user_dir = _wcsdup(buf);
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20975#issuecomment-2348157528

From alanb at openjdk.org  Fri Sep 13 06:52:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Sep 2024 06:52:10 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
 <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
Message-ID: <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>

On Fri, 13 Sep 2024 06:32:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This PR fixes a regression introduced by https://github.com/openjdk/jdk/pull/20848
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 313:
> 
>> 311:     // The returned value is in the interval [0, 2^30]
>> 312:     static int powerOfPropertyOr(String name, int defaultPower) {
>> 313:         final String property = GetPropertyAction.privilegedGetProperty(PROPERTY_PATH + name);
> 
> Hello Per, `sun.security.action.GetIntegerAction.privilegedGetProperty(PROPERTY_PATH + name, defaultPower)` could avoid the null checks and the try blocks here.

Yes, the 2-arg GetIntegerAction.privilegedGetProperty would be better here, and it would retain the existing behavior for when the property value can't be parsed as a number.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758277128

From pminborg at openjdk.org  Fri Sep 13 06:52:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 06:52:10 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
 <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
 <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>
Message-ID: <UtTVS0ZiPLIQJFT0S9nOrhgQb4DMwbqqvC9akJ3tZzk=.605c8472-c452-4b6c-9365-174d3241ec2e@github.com>

On Fri, 13 Sep 2024 06:49:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 313:
>> 
>>> 311:     // The returned value is in the interval [0, 2^30]
>>> 312:     static int powerOfPropertyOr(String name, int defaultPower) {
>>> 313:         final String property = GetPropertyAction.privilegedGetProperty(PROPERTY_PATH + name);
>> 
>> Hello Per, `sun.security.action.GetIntegerAction.privilegedGetProperty(PROPERTY_PATH + name, defaultPower)` could avoid the null checks and the try blocks here.
>
> Yes, the 2-arg GetIntegerAction.privilegedGetProperty would be better here, and it would retain the existing behavior for when the property value can't be parsed as a number.

I think we need the try block anyhow as we have to deal with a String. But might be slightly better. We could revisit this later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758277278

From pminborg at openjdk.org  Fri Sep 13 06:52:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 06:52:11 GMT
Subject: Integrated: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
Message-ID: <YSbViE3NFwcSqfuAVLeF6aclqwQVdqiL4ITw-FV2A00=.10fe4c61-360a-4efa-9926-2404e4e720ba@github.com>

On Fri, 13 Sep 2024 06:25:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a regression introduced by https://github.com/openjdk/jdk/pull/20848

This pull request has now been integrated.

Changeset: 5709c379
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5709c379408d8919b86bbad6635b97756461ab27
Stats:     10 lines in 1 file changed: 8 ins; 0 del; 2 mod

8340081: Test java/foreign/TestLinker.java failed failed: missing permission java.lang.foreign.native.threshold.power.fill

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/20983

From pminborg at openjdk.org  Fri Sep 13 06:56:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 06:56:08 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <UtTVS0ZiPLIQJFT0S9nOrhgQb4DMwbqqvC9akJ3tZzk=.605c8472-c452-4b6c-9365-174d3241ec2e@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
 <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
 <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>
 <UtTVS0ZiPLIQJFT0S9nOrhgQb4DMwbqqvC9akJ3tZzk=.605c8472-c452-4b6c-9365-174d3241ec2e@github.com>
Message-ID: <NKW7nuJNnP0qNnIYa4Z5bitCHeLBhWO_hDNN1QrAKSg=.cc8a9d9e-f248-4dc2-9d9f-4a279bef7b28@github.com>

On Fri, 13 Sep 2024 06:49:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Yes, the 2-arg GetIntegerAction.privilegedGetProperty would be better here, and it would retain the existing behavior for when the property value can't be parsed as a number.
>
> I think we need the try block anyhow as we have to deal with a String. But might be slightly better. We could revisit this later.

It would look like this:


    static int powerOfPropertyOr(String name, int defaultPower) {
        final String property = GetPropertyAction.privilegedGetProperty(PROPERTY_PATH + name, Integer.toString(defaultPower));
        try {
            return 1 << Math.clamp(Integer.parseInt(property), 0, Integer.SIZE - 2);
        } catch (NumberFormatException _) {
            // ignore
        }
        return defaultPower;
    }
    ```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758281092

From pminborg at openjdk.org  Fri Sep 13 07:01:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:01:09 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <NKW7nuJNnP0qNnIYa4Z5bitCHeLBhWO_hDNN1QrAKSg=.cc8a9d9e-f248-4dc2-9d9f-4a279bef7b28@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
 <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
 <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>
 <UtTVS0ZiPLIQJFT0S9nOrhgQb4DMwbqqvC9akJ3tZzk=.605c8472-c452-4b6c-9365-174d3241ec2e@github.com>
 <NKW7nuJNnP0qNnIYa4Z5bitCHeLBhWO_hDNN1QrAKSg=.cc8a9d9e-f248-4dc2-9d9f-4a279bef7b28@github.com>
Message-ID: <EQ3f0zcZ_SM_7T9ENmu2ibCqOct0vZ7fXLqdt4U9YmU=.9ae1cc6e-f2c1-4364-ade9-1220969aef39@github.com>

On Fri, 13 Sep 2024 06:53:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I think we need the try block anyhow as we have to deal with a String. But might be slightly better. We could revisit this later.
>
> It would look like this:
> 
> 
>     static int powerOfPropertyOr(String name, int defaultPower) {
>         final String property = GetPropertyAction.privilegedGetProperty(PROPERTY_PATH + name, Integer.toString(defaultPower));
>         try {
>             return 1 << Math.clamp(Integer.parseInt(property), 0, Integer.SIZE - 2);
>         } catch (NumberFormatException _) {
>             // ignore
>         }
>         return defaultPower;
>     }
>     ```

https://bugs.openjdk.org/browse/JDK-8340089

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758284454

From jpai at openjdk.org  Fri Sep 13 07:01:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 07:01:09 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <EQ3f0zcZ_SM_7T9ENmu2ibCqOct0vZ7fXLqdt4U9YmU=.9ae1cc6e-f2c1-4364-ade9-1220969aef39@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
 <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
 <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>
 <UtTVS0ZiPLIQJFT0S9nOrhgQb4DMwbqqvC9akJ3tZzk=.605c8472-c452-4b6c-9365-174d3241ec2e@github.com>
 <NKW7nuJNnP0qNnIYa4Z5bitCHeLBhWO_hDNN1QrAKSg=.cc8a9d9e-f248-4dc2-9d9f-4a279bef7b28@github.com>
 <EQ3f0zcZ_SM_7T9ENmu2ibCqOct0vZ7fXLqdt4U9YmU=.9ae1cc6e-f2c1-4364-ade9-1220969aef39@github.com>
Message-ID: <Vod5oClv1funW9rrisSErdm1sN0xMkPyO4bnaCAIr3A=.b8f2d09d-ad96-4953-af35-7c5afb38c821@github.com>

On Fri, 13 Sep 2024 06:56:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> It would look like this:
>> 
>> 
>>     static int powerOfPropertyOr(String name, int defaultPower) {
>>         final String property = GetPropertyAction.privilegedGetProperty(PROPERTY_PATH + name, Integer.toString(defaultPower));
>>         try {
>>             return 1 << Math.clamp(Integer.parseInt(property), 0, Integer.SIZE - 2);
>>         } catch (NumberFormatException _) {
>>             // ignore
>>         }
>>         return defaultPower;
>>     }
>>     ```
>
> https://bugs.openjdk.org/browse/JDK-8340089

I think there's a oversight here. What we meant was a separate GetIntegerAction class instead of GetPropertyAction. The code would then look like:


final int power = sun.security.action.GetIntegerAction.privilegedGetProperty(PROPERTY_PATH + name, defaultPower);
return 1 << Math.clamp(power, 0, Integer.SIZE - 2);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758286910

From pminborg at openjdk.org  Fri Sep 13 07:10:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:10:34 GMT
Subject: RFR: 8340089: Simplify SegmentBulkOperations::powerOfProperty
Message-ID: <vHjx5LdZ-ZFIw3hFNSh6s6tJqH58mXfRa7Awwpl62-g=.f04b6b9e-e001-466f-a6ef-a80fe648cabd@github.com>

This PR suggests to simplify the. method `SegmebtBulkOperations::powerOfPropertyOr`.

-------------

Commit messages:
 - Fix merge error
 - Merge master
 - Simplify further
 - Simplify method
 - Use privilegedGetProperty

Changes: https://git.openjdk.org/jdk/pull/20985/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20985&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340089
  Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20985/head:pull/20985

PR: https://git.openjdk.org/jdk/pull/20985

From pminborg at openjdk.org  Fri Sep 13 07:11:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:11:09 GMT
Subject: RFR: 8340081: Test java/foreign/TestLinker.java failed failed:
 missing permission java.lang.foreign.native.threshold.power.fill
In-Reply-To: <Vod5oClv1funW9rrisSErdm1sN0xMkPyO4bnaCAIr3A=.b8f2d09d-ad96-4953-af35-7c5afb38c821@github.com>
References: <ol0pPqioyyfhCqMoQe652ZGpIFLgBs2aV5mt9UF-HHk=.1156fd95-0495-4265-9958-4e6e19f3cea5@github.com>
 <f2p4OBvU7LuIJMZ0lOoF_QkrjtqqxS1U9JxEPijl5s4=.3773f916-28a2-45a5-ac45-d7dae3b813b7@github.com>
 <kcl5PoxlKdPE9DuX-SYIR8AshRNvZkhqdp_jZhAJDZg=.a8a6685e-3293-4840-ba4d-1b57cc57a3cd@github.com>
 <UtTVS0ZiPLIQJFT0S9nOrhgQb4DMwbqqvC9akJ3tZzk=.605c8472-c452-4b6c-9365-174d3241ec2e@github.com>
 <NKW7nuJNnP0qNnIYa4Z5bitCHeLBhWO_hDNN1QrAKSg=.cc8a9d9e-f248-4dc2-9d9f-4a279bef7b28@github.com>
 <EQ3f0zcZ_SM_7T9ENmu2ibCqOct0vZ7fXLqdt4U9YmU=.9ae1cc6e-f2c1-4364-ade9-1220969aef39@github.com>
 <Vod5oClv1funW9rrisSErdm1sN0xMkPyO4bnaCAIr3A=.b8f2d09d-ad96-4953-af35-7c5afb38c821@github.com>
Message-ID: <f42uesBSY-JN6A8qQqCK0_bhd8tcYekgsyP1B_GKCEo=.4d34cd4c-e4ce-4f34-94b6-f6bb5b664f60@github.com>

On Fri, 13 Sep 2024 06:58:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8340089
>
> I think there's a oversight here. What we meant was a separate GetIntegerAction class instead of GetPropertyAction. The code would then look like:
> 
> 
> final int power = sun.security.action.GetIntegerAction.privilegedGetProperty(PROPERTY_PATH + name, defaultPower);
> return 1 << Math.clamp(power, 0, Integer.SIZE - 2);

https://github.com/openjdk/jdk/pull/20985

Thanks for spotting this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20983#discussion_r1758298577

From jpai at openjdk.org  Fri Sep 13 07:19:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 07:19:04 GMT
Subject: RFR: 8340089: Simplify SegmentBulkOperations::powerOfProperty
In-Reply-To: <vHjx5LdZ-ZFIw3hFNSh6s6tJqH58mXfRa7Awwpl62-g=.f04b6b9e-e001-466f-a6ef-a80fe648cabd@github.com>
References: <vHjx5LdZ-ZFIw3hFNSh6s6tJqH58mXfRa7Awwpl62-g=.f04b6b9e-e001-466f-a6ef-a80fe648cabd@github.com>
Message-ID: <2ZyxBtyWdypFr29LSFUv_9Bt4if5jHyo5Sp-YHS4GEc=.d003fd90-bb5f-4f62-9de2-b10812f9e26f@github.com>

On Fri, 13 Sep 2024 07:04:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests to simplify the. method `SegmebtBulkOperations::powerOfPropertyOr`.

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20985#pullrequestreview-2302296551

From duke at openjdk.org  Fri Sep 13 07:32:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 13 Sep 2024 07:32:14 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <iJXmbY-RQ-jmbO73tOzXhykq8zxAaOrSK9-K4v0cl3k=.8b50d943-7071-47ba-92da-b5f322d214ce@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

The?old?version of?the?doc?comments had?a?`.` at?the?end of?the?first?sentence:

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1221:

> 1219: 
> 1220:             /**
> 1221:              * {@return the pattern used to create this filter}

Suggestion:

             * {@return the pattern used to create this filter}.

src/java.base/share/classes/java/io/ObjectInputStream.java line 3862:

> 3860: 
> 3861:         /**
> 3862:          * {@return the number of bytes read from the input stream}

Suggestion:

         * {@return the number of bytes read from the input stream}.

src/java.base/share/classes/java/lang/annotation/Retention.java line 48:

> 46: public @interface Retention {
> 47:     /**
> 48:      * {@return the retention policy}

Suggestion:

     * {@return the retention policy}.

src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 59:

> 57: 
> 58:     /**
> 59:      * {@return the length of the input}

Suggestion:

     * {@return the length of the input}.

src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 66:

> 64: 
> 65:     /**
> 66:      * {@return the message}

Suggestion:

     * {@return the message}.

src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java line 59:

> 57: 
> 58:     /**
> 59:      * {@return the length of the input}

Suggestion:

     * {@return the length of the input}.

src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java line 66:

> 64: 
> 65:     /**
> 66:      * {@return the message}

Suggestion:

     * {@return the message}.

src/java.base/share/classes/java/time/format/TextStyle.java line 140:

> 138: 
> 139:     /**
> 140:      * {@return the stand-alone style with the same size}

Suggestion:

     * {@return the stand-alone style with the same size}.

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 480:

> 478: 
> 479:     /**
> 480:      * {@return a zero-length array}

Suggestion:

     * {@return a zero-length array}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java line 179:

> 177: 
> 178:     /**
> 179:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java line 343:

> 341: 
> 342:     /**
> 343:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java line 369:

> 367: 
> 368:     /**
> 369:      * {@return the String representation of the current values of array}

Suggestion:

     * {@return the String representation of the current values of array}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java line 344:

> 342: 
> 343:     /**
> 344:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java line 369:

> 367: 
> 368:     /**
> 369:      * {@return the String representation of the current values of array}

Suggestion:

     * {@return the String representation of the current values of array}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java line 272:

> 270: 
> 271:     /**
> 272:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java line 300:

> 298: 
> 299:     /**
> 300:      * {@return the String representation of the current values of array}

Suggestion:

     * {@return the String representation of the current values of array}.

src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java line 192:

> 190: 
> 191:     /**
> 192:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java line 186:

> 184: 
> 185:     /**
> 186:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/jar/Manifest.java line 122:

> 120: 
> 121:     /**
> 122:      * {@return the main Attributes for the Manifest}

Suggestion:

     * {@return the main Attributes for the Manifest}.

src/java.base/share/classes/java/util/zip/Deflater.java line 785:

> 783: 
> 784:     /**
> 785:      * {@return the ADLER-32 value of the uncompressed data}

Suggestion:

     * {@return the ADLER-32 value of the uncompressed data}.

src/java.base/share/classes/java/util/zip/Inflater.java line 285:

> 283: 
> 284:     /**
> 285:      * {@return true if a preset dictionary is needed for decompression}

Suggestion:

     * {@return true if a preset dictionary is needed for decompression}.

src/java.base/share/classes/java/util/zip/Inflater.java line 296:

> 294:     /**
> 295:      * {@return true if the end of the compressed data stream has been
> 296:      * reached}

Suggestion:

     * {@return true if the end of the compressed data stream has been
     * reached}.

src/java.base/share/classes/java/util/zip/Inflater.java line 602:

> 600: 
> 601:     /**
> 602:      * {@return the ADLER-32 value of the uncompressed data}

Suggestion:

     * {@return the ADLER-32 value of the uncompressed data}.

src/java.base/share/classes/java/util/zip/ZipEntry.java line 141:

> 139: 
> 140:     /**
> 141:      * {@return the name of the entry}

Suggestion:

     * {@return the name of the entry}.

src/java.base/share/classes/java/util/zip/ZipFile.java line 501:

> 499: 
> 500:     /**
> 501:      * {@return the path name of the ZIP file}

Suggestion:

     * {@return the path name of the ZIP file}.

src/java.base/share/classes/java/util/zip/ZipFile.java line 562:

> 560: 
> 561:     /**
> 562:      * {@return an enumeration of the ZIP file entries}

Suggestion:

     * {@return an enumeration of the ZIP file entries}.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302321414
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326174
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326396
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326761
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327147
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327483
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327766
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327939
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328188
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328373
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328561
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328660
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328760
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328833
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328935
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329031
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329171
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329268
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329376
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329468
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329520
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329601
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329771
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329873
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330051
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330157
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330290

From pminborg at openjdk.org  Fri Sep 13 07:42:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:42:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
Message-ID: <B1uEx0TTADwiXuEDS6SbS5_t0fYnd8u_lhUkmKWYiSU=.e9c8ff40-9cd3-45b3-8483-8a87efd33c4e@github.com>

On Thu, 12 Sep 2024 19:29:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think we can elide the `Lookup` argument to perform a always-full-permission lookup operation to simplify call sequence; or, to elide the `recv` receiver argument as it is almost always `lookup.lookupClass()` (except for a few lazy holders)

If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as a lookup and elide the lookup arg. Any ideas to do this in a "polite" way?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2348250197

From pminborg at openjdk.org  Fri Sep 13 07:50:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:50:49 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |             10255 |           10154 |
> | AtomicBoolean.class                   |              5364 |             5161 |
> |AtomicMarkableReference.class |              3890 |            3687 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |        5963657 |
> | Patch                |        5962751 |
> | Delta                 |                906|
> 
> For 60 billion instances, this represents 54 TB.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename and reformat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/87d7a477..1dee24ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=00-01

  Stats: 98 lines in 31 files changed: 32 ins; 3 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From alanb at openjdk.org  Fri Sep 13 07:50:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Sep 2024 07:50:49 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <B1uEx0TTADwiXuEDS6SbS5_t0fYnd8u_lhUkmKWYiSU=.e9c8ff40-9cd3-45b3-8483-8a87efd33c4e@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
 <B1uEx0TTADwiXuEDS6SbS5_t0fYnd8u_lhUkmKWYiSU=.e9c8ff40-9cd3-45b3-8483-8a87efd33c4e@github.com>
Message-ID: <VhyXXaahqZbPl04iYbJLo-4VpRisviFkhhqklPTxVWk=.b6d4a9cb-a2f5-4fe4-ad57-9b39c2e0440b@github.com>

On Fri, 13 Sep 2024 07:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as a lookup and elide the lookup arg. Any ideas to do this in a "polite" way?

Lookup.IMPL_LOOKUP should be guarded closely, I don't think we should remove the need to provide a Lookup with the appropriate access.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2348266276

From pminborg at openjdk.org  Fri Sep 13 08:46:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 08:46:08 GMT
Subject: Integrated: 8340089: Simplify SegmentBulkOperations::powerOfProperty
In-Reply-To: <vHjx5LdZ-ZFIw3hFNSh6s6tJqH58mXfRa7Awwpl62-g=.f04b6b9e-e001-466f-a6ef-a80fe648cabd@github.com>
References: <vHjx5LdZ-ZFIw3hFNSh6s6tJqH58mXfRa7Awwpl62-g=.f04b6b9e-e001-466f-a6ef-a80fe648cabd@github.com>
Message-ID: <_dAtl4gNe91sNshTsg1VLBKIevsZHNG1yH3gaVUQo5s=.e35ce14d-5f74-4c3b-b7b3-0534eac2e1d4@github.com>

On Fri, 13 Sep 2024 07:04:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests to simplify the. method `SegmebtBulkOperations::powerOfPropertyOr`.

This pull request has now been integrated.

Changeset: 0c36177f
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c36177fead8b64a4cee9da3c895e3799f8ba231
Stats:     10 lines in 1 file changed: 0 ins; 7 del; 3 mod

8340089: Simplify SegmentBulkOperations::powerOfProperty

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/20985

From rgiulietti at openjdk.org  Fri Sep 13 08:56:39 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Sep 2024 08:56:39 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method [v2]
In-Reply-To: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
Message-ID: <VeVKQLO2yVoDsvdrz3aYqe-JnA7teVnVLMrEOyiAcx4=.ce3c56c9-196c-4e18-a4cd-58039126d597@github.com>

> `Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Slight improvement.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20948/files
  - new: https://git.openjdk.org/jdk/pull/20948/files/dce181b4..2b7c7061

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20948&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20948&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20948/head:pull/20948

PR: https://git.openjdk.org/jdk/pull/20948

From prappo at openjdk.org  Fri Sep 13 09:16:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 09:16:05 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <iJXmbY-RQ-jmbO73tOzXhykq8zxAaOrSK9-K4v0cl3k=.8b50d943-7071-47ba-92da-b5f322d214ce@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
 <iJXmbY-RQ-jmbO73tOzXhykq8zxAaOrSK9-K4v0cl3k=.8b50d943-7071-47ba-92da-b5f322d214ce@github.com>
Message-ID: <WIBkJB7ZD3VqCBawUTXrDKGxEaG2A-x8N62Rc_YiW4g=.21341179-4f81-490d-b898-4ed6ad63a7f9@github.com>

On Fri, 13 Sep 2024 07:29:00 GMT, ExE Boss <duke at openjdk.org> wrote:

> The?old?version of?the?doc?comments had?a?`.` at?the?end of?the?first?sentence:

The new version has it too, but in the final, generated form: https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html#return

`{@return blah}` expands to `Returns blah.`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348446043

From aturbanov at openjdk.org  Fri Sep 13 09:30:18 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 13 Sep 2024 09:30:18 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v4]
In-Reply-To: <Zvt0oBc6PixHG-jBP_bYY43luNYFx7EaKavguoRhVU4=.73b88f9d-394f-4aca-ac1c-456771cf3ca3@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <Zvt0oBc6PixHG-jBP_bYY43luNYFx7EaKavguoRhVU4=.73b88f9d-394f-4aca-ac1c-456771cf3ca3@github.com>
Message-ID: <wXE6ID1XH0g6BJwMiILbx3F3PUCs2LPAvpahD7rkEhM=.42e22e91-c4e5-4cb8-98d2-ed97bef8515b@github.com>

On Wed, 11 Sep 2024 00:29:30 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   c1 and template generator fixes

test/jdk/java/lang/Math/HyperbolicTests.java line 1011:

> 1009:         }
> 1010: 
> 1011:         for(int i = 0; i < testCases.length; i++) {

Suggestion:

        for (int i = 0; i < testCases.length; i++) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1758522740

From mcimadamore at openjdk.org  Fri Sep 13 09:30:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 09:30:20 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths [v2]
In-Reply-To: <R7BBNrbnkpWXPRSUp-QvxPYGTFqqKh5SKHBHdlq1wrk=.b040a4f3-979a-4af1-ba27-a3a7dd2c8244@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <R7BBNrbnkpWXPRSUp-QvxPYGTFqqKh5SKHBHdlq1wrk=.b040a4f3-979a-4af1-ba27-a3a7dd2c8244@github.com>
Message-ID: <UnlrslzhZTW_Dl62ET6xrpFBFagsWQ0dp_ZUA_Ihpi8=.7cfd7a8b-3da5-4255-a8b8-468bb13cad66@github.com>

On Thu, 12 Sep 2024 12:44:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.
>
> 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 10 additional commits since the last revision:
> 
>  - Remove trailing blanks
>  - Add back extra line break
>  - Add copyright year
>  - Update copyright year
>  - Revoke change to copyright year
>  - Reinstate code
>  - Move logic to doc
>  - Merge branch 'master' into ms-string-known-length
>  - Add copyright year
>  - Add MemorySegment::getString overload

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1290:

> 1288:      * Getting a String from a {@code segment} with a known byte {@code offset} and
> 1289:      * known byte {@code length} can be done like so:
> 1290:      * {@snippet lang=java

A semicolon at the end of the line is missing - this is causing build issues in the github action:


/home/runner/work/jdk/jdk/src/java.base/share/classes/java/lang/foreign/MemorySegment.java:1291: error: unexpected content
     *     byte[] bytes = new byte[length];
              ^

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1758521557

From duke at openjdk.org  Fri Sep 13 09:48:05 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 13 Sep 2024 09:48:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
Message-ID: <tlQB7aJJWcsBwvCCgbjAqMCU8HMzO4-rVby3KkB9DnE=.0ea5b060-9d7b-4615-b17d-37ae32353527@github.com>

On Thu, 12 Sep 2024 19:30:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename and reformat
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 1:
> 
>> 1: /*
> 
> I would argue this is closer to invoke than reflect, so can consider moving to `sun.invoke` or even create a new `jdk.internal.invoke` package.

I?m?in?favour of?introducing `jdk.internal.invoke`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758550297

From orionllmain at gmail.com  Fri Sep 13 09:49:04 2024
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Fri, 13 Sep 2024 14:49:04 +0500
Subject: How many methods have been deprecated in sun.misc.Unsafe? (JEP 471)
Message-ID: <CAF2POUf424DzVx=mL6BCh9n7RF8x7iC+PwXdOo3h24T4ceo7Pw@mail.gmail.com>

Hello!

JEP 471 says that 79 methods out of 87 have been deprecated in
sun.misc.Unsafe. However, I have a different number.

Deprecated for removal in Java 18:
1. public long objectFieldOffset(Field f)
2. public Object staticFieldBase(Field f)
3. public long staticFieldOffset(Field f)

Deprecated for removal in Java 23:
1. public int addressSize()
2. public long allocateMemory(long bytes)
3. public int arrayBaseOffset(Class<?> arrayClass)
4. public int arrayIndexScale(Class<?> arrayClass)
5. public final boolean compareAndSwapInt(Object o, long offset, int
expected, int x)
6. public final boolean compareAndSwapLong(Object o, long offset,  long
expected, long x)
7. public final boolean compareAndSwapObject(Object o, long offset, Object
expected, Object x)
8. public void copyMemory(Object srcBase, long srcOffset, Object destBase,
long destOffset, long bytes)
9. public void copyMemory(long srcAddress, long destAddress, long bytes)
10. public void freeMemory(long address)
11. public long getAddress(long address)
12. public final int getAndAddInt(Object o, long offset, int delta)
13. public final long getAndAddLong(Object o, long offset, long delta)
14. public final int getAndSetInt(Object o, long offset, int newValue)
15. public final long getAndSetLong(Object o, long offset, long newValue)
16. public final Object getAndSetObject(Object o, long offset, Object
newValue)
17. public boolean getBoolean(Object o, long offset)
18. public boolean getBooleanVolatile(Object o, long offset)
19. public byte getByte(Object o, long offset)
20. public byte getByte(long address)
21. public byte getByteVolatile(Object o, long offset)
22. public char getChar(Object o, long offset)
23. public char getChar(long address)
24. public char getCharVolatile(Object o, long offset)
25. public double getDouble(Object o, long offset)
26. public double getDouble(long address)
27. public double getDoubleVolatile(Object o, long offset)
28. public float getFloat(Object o, long offset)
29. public float getFloat(long address)
30. public float getFloatVolatile(Object o, long offset)
31. public int getInt(Object o, long offset)
32. public int getInt(long address)
33. public int getIntVolatile(Object o, long offset)
34. public long getLong(Object o, long offset)
35. public long getLong(long address)
36. public long getLongVolatile(Object o, long offset)
37. public Object getObject(Object o, long offset)
38. public Object getObjectVolatile(Object o, long offset)
39. public short getShort(Object o, long offset)
40. public short getShort(long address)
41. public short getShortVolatile(Object o, long offset)
42. public void invokeCleaner(java.nio.ByteBuffer directBuffer)
43. public void putAddress(long address, long x)
44. public void putBoolean(Object o, long offset, boolean x)
45. public void putBooleanVolatile(Object o, long offset, boolean x)
46. public void putByte(Object o, long offset, byte x)
47. public void putByte(long address, byte x)
48. public void putByteVolatile(Object o, long offset, byte x)
49. public void putChar(Object o, long offset, char x)
50. public void putChar(long address, char x)
51. public void putCharVolatile(Object o, long offset, char x)
52. public void putDouble(Object o, long offset, double x)
53. public void putDouble(long address, double x)
54. public void putDoubleVolatile(Object o, long offset, double x)
55. public void putFloat(Object o, long offset, float x)
56. public void putFloat(long address, float x)
57. public void putFloatVolatile(Object o, long offset, float x)
58. public void putInt(Object o, long offset, int x)
59. public void putInt(long address, int x)
60. public void putIntVolatile(Object o, long offset, int x)
61. public void putLong(Object o, long offset, long x)
62. public void putLong(long address, long x)
63. public void putLongVolatile(Object o, long offset, long x)
64. public void putObject(Object o, long offset, Object x)
65. public void putObjectVolatile(Object o, long offset, Object x)
66. public void putOrderedInt(Object o, long offset, int x)
67. public void putOrderedLong(Object o, long offset, long x)
68. public void putOrderedObject(Object o, long offset, Object x)
69. public void putShort(Object o, long offset, short x)
70. public void putShort(long address, short x)
71. public void putShortVolatile(Object o, long offset, short x)
72. public long reallocateMemory(long address, long bytes)
73. public void setMemory(Object o, long offset, long bytes, byte value)
74. public void setMemory(long address, long bytes, byte value)

So, my list says that* the total count is 3+74=77 (not 79).*

The rest of methods:

Deprecated for removal in Java 22 (not for memory access):
1. public void fullFence()
2. public int getLoadAverage(double[] loadavg, int nelems)
3. public void loadFence()
4. public void park(boolean isAbsolute, long time)
5. public void storeFence()
6. public void unpark(Object thread)

Not deprecated yet:
1. public int pageSize()
2. public Object allocateInstance(Class<?> cls)
3. public void throwException(Throwable ee)
4. public static Unsafe getUnsafe()

So, the total number of methods is (3+74)+(6+4)=87. This is correct (JEP
also says 87).

Should the number in the JEP be fixed? (79 out of 87 -> 77 out of 87).


Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240913/11a33147/attachment.htm>

From prappo at openjdk.org  Fri Sep 13 10:24:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 10:24:04 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <63jr3o7GvnCQc-Fftek57SoIO58BsAblgKia69hF5fo=.733822a2-8ba0-42fd-a6bb-eb7bcb641bbc@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Thanks, Joe. This looks good, especially considering that the change was produced with the help of a quick-and-dirty, regex-based script. This change is certainly enough to spread awareness of this relatively new javadoc feature.

I remember I had a more involved script that used `javax.lang.model` and string similarity metrics. That script captured a lot more candidates for `{@return}`. But on the other hand, once you start considering non-exact matches, it requires human judgement and increases review effort.

---

Separately, this PR has helped me put a finger on what I __don't__ like about `{@return}`. What I don't like is the generated HTML. `{@return}` saves mental effort when reading raw javadoc in source, but it provides no similar service to the reader of the final, HTML form. Maybe it's just me, but it looks needlessly bloated and silly:

<img width="201" alt="browser screenshot of javax.lang.model.element.AnnotationValue#getValue" src="https://github.com/user-attachments/assets/1a7ee92f-7006-4b09-bc50-e23d9148c3ad">

Maybe if a method's main description consisted only of `{@return}`, we could skip the first sentence in the "Method Details" section and just output `Returns:`? Any further discussion should happen on the javadoc-dev mailing list.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302744094

From pminborg at openjdk.org  Fri Sep 13 10:27:27 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 10:27:27 GMT
Subject: RFR: 8333843: Provide guidelines on MemorySegment to read strings
 with known lengths [v3]
In-Reply-To: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
Message-ID: <m49Cpb2ESSKZMaPNl4TMPQ4s_CEzL6bXp3gW0P6J5TQ=.d8109b3b-24df-4288-8dc4-6410c5307555@github.com>

> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update after comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20725/files
  - new: https://git.openjdk.org/jdk/pull/20725/files/cc862a05..976d4465

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20725&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20725&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20725/head:pull/20725

PR: https://git.openjdk.org/jdk/pull/20725

From mcimadamore at openjdk.org  Fri Sep 13 11:53:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 11:53:05 GMT
Subject: RFR: 8333843: Provide guidelines on MemorySegment to read strings
 with known lengths [v3]
In-Reply-To: <m49Cpb2ESSKZMaPNl4TMPQ4s_CEzL6bXp3gW0P6J5TQ=.d8109b3b-24df-4288-8dc4-6410c5307555@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <m49Cpb2ESSKZMaPNl4TMPQ4s_CEzL6bXp3gW0P6J5TQ=.d8109b3b-24df-4288-8dc4-6410c5307555@github.com>
Message-ID: <xFZ_1p3f8PRbqqWsDJI665BKZEYpp_wEpuOAqArBgf0=.840e4424-aef4-4e04-b260-1c682759bee2@github.com>

On Fri, 13 Sep 2024 10:27:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

Changes look good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20725#pullrequestreview-2302909492

From jpai at openjdk.org  Fri Sep 13 12:00:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 12:00:10 GMT
Subject: Withdrawn: 8339332: Clean up the java launcher code
In-Reply-To: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
References: <LKln3A1MScj9-RngHnvsWtRkPid59aD5lYRYfDa1L0k=.9b2a45b6-4acc-4086-b770-30d1fe7d88c1@github.com>
Message-ID: <aO95H01vjgqbI-gz9tupc-DlqAAwMWkOVXGdXMxfRnQ=.3b7f59ad-0ae6-4e38-ae04-08c72bb3b531@github.com>

On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the code in the `java` launcher? The original motivation for the change was to prevent the `java` launcher's C code from parsing a jar's manifest when launching an application through `java -jar foo.jar`. The jar parsing code in C currently doesn't have the same level of robustness and features as what's available in the Java side implementation of `Zip/JarFile` API in `java.util.zip`. Among them, one is the lack of ZIP64 support in the launcher's jar parsing code. That issue was noticed in https://bugs.openjdk.org/browse/JDK-8328995 and a PR (https://github.com/openjdk/jdk/pull/18479) was proposed to enhance this C code in the launcher to support ZIP64 jar files. Even before the proposed changes in that PR, there already were a few concerns about long term maintainability of the jar parsing code in the launcher given that it duplicates what we already do in the Java side implementation, so adding new C code here isn't prefer
 able.
> 
> The change in this current PR removes the part where the launcher's C code was parsing the jar's manifest file to identify "Main-Class" and "SplashScreen-Image" attributes from the manifest of the jar that was being launched. This was being done in the C code to support a long outdated "JRE selection" feature (mJRE https://bugs.openjdk.org/browse/JDK-8058407) which required it to parse the jar's manifest. After that feature was removed, the sole reason the jar's manifest was continued to be parsed in this launcher code was for convenience.
> 
> With the changes proposed in this PR, the launcher will use the jar parsing C code only if the jar has a "SplashScreen-Image" in its manifest. The number of such jars, based on an experiment against a large corpus of jar files, is very minimal (we found just 26 jars in around 900K odd jar files with a "SplashScreen-Image"). The updated code in this PR also delegates the identification of the "SplashScreen-Image" attribute to the java code (in `LauncherHelper`) thus removing the need to parse the manifest in C code. The only time the C code will now do the jar parsing is to display a splash screen image (if any is present) from the jar file. I think even that can be avoided, but I haven't experimented with it and I would like to pursue that separately in future, instead of this PR.
> 
> Finally, a few of the utility functions that were introduced in the launcher C code in a recent JEP to support "Implicitly Declared Classes and Instance Main...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20929

From lancea at openjdk.org  Fri Sep 13 12:18:04 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Sep 2024 12:18:04 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <YByg4js_VhMFPvLfzkDn76B_lWK8Iz85WjG-dCaGIKM=.841a4999-de88-4bca-b224-d36f4513f605@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

I went through the changes and they look fine.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302964654

From jpai at openjdk.org  Fri Sep 13 12:34:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 12:34:14 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow
Message-ID: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>

Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?

As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.

While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.

An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.

No new tests have been introduced in this PR and tier testing is currently in progress.

-------------

Commit messages:
 - 8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow

Changes: https://git.openjdk.org/jdk/pull/20997/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340114
  Stats: 541 lines in 7 files changed: 99 ins; 306 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From liach at openjdk.org  Fri Sep 13 12:43:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 12:43:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
Message-ID: <n-SerjbIumSRZ58QnRyJtCXviqFOlHl7ROlK4iLGTrw=.fb21b7b0-6a09-4605-aa53-e5f51725fac1@github.com>

On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |             10255 |           10154 |
>> | AtomicBoolean.class                   |              5364 |             5161 |
>> |AtomicMarkableReference.class |              3890 |            3687 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |        5963657 |
>> | Patch                |        5962751 |
>> | Delta                 |                906|
>> 
>> For 60 billion instances, this represents 54 TB.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename and reformat

src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 50:

> 48:     private MethodHandlesInternal() {}
> 49: 
> 50:     public static VarHandle findVarHandle(MethodHandles.Lookup lookup,

Do you think we should create a 3-arg overload like `Lookup lookup, String name, Class<?> type` that calls `findVarHandle(lookup, lookup.lookupClass(), name, type);` for ease of use at many call sites?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758795681

From duke at openjdk.org  Fri Sep 13 13:06:14 2024
From: duke at openjdk.org (Brett Okken)
Date: Fri, 13 Sep 2024 13:06:14 GMT
Subject: RFR: 8339531: Improve performance of MemorySegment::mismatch [v9]
In-Reply-To: <L_eysRv6ew-6Vp6IPqXUhQXlKrUgr88w5Qlk_nl9Nss=.1a388afc-75cf-4579-bdf7-73c16f9f8b2c@github.com>
References: <BOrSqrCZIXy9HOCBAjexwHx5Iz9Q9a1Fgea25WQjqDs=.02afc206-d70f-4b73-935f-f6361f086c19@github.com>
 <gAKk2-MLX05MXKvvbwtQt0RX_3oHBv5yIS9TuG25m7U=.503a68df-cb52-4a29-b723-28cd495bd3bf@github.com>
 <AYbLj-T19q6gIcFEisoGFkkbQlpJ3Lzm-LjXwazsSE0=.61cdf34f-0c59-408b-bb2d-1150997d7e5d@github.com>
 <L_eysRv6ew-6Vp6IPqXUhQXlKrUgr88w5Qlk_nl9Nss=.1a388afc-75cf-4579-bdf7-73c16f9f8b2c@github.com>
Message-ID: <bF3I8BP4J61FkK5-MOV3uaEAH4e8nIznTrzsElzLus0=.f9c2525a-7241-477b-a5d9-161926b9c08a@github.com>

On Wed, 11 Sep 2024 13:15:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 244:
>> 
>>> 242:         return (Architecture.isLittleEndian()
>>> 243:                 ? Long.numberOfTrailingZeros(x)
>>> 244:                 : Long.numberOfLeadingZeros(x)) / 8;
>> 
>> Would there be value in having a constant LongToIntFunction lambda to capture this logic?
>> 
>> 
>> private static final LongToIntFunction LONG_LEADING_ZEROS = Architecture.isLittleEndian() ? Long::numberOfTrailingZeros : Long::numberOfLeadingZeros;
>
> Performance-wise, I suspect there would not be that much of a difference. The compiler will see that Architecture.isLittleEndian provides a stable value and can optimize and eliminate code (I think). I am unsure which is easier to read.

part of the value would be if it allowed just removing this method entirely and moving the logic above:


            if (s != d) {
                return start + offset + mismatch(s, d);
            }


would become:


            if (s != d) {
                return start + offset + (LONG_LEADING_ZEROS.apply(s^d) / 8);
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1758828018

From pminborg at openjdk.org  Fri Sep 13 13:07:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 13:07:46 GMT
Subject: RFR: 8340120: Out of bounds addressing in mismatch
Message-ID: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>

This PR fixes a build error where we addressed out of bounds.

-------------

Commit messages:
 - Remove redundant code

Changes: https://git.openjdk.org/jdk/pull/20998/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20998&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340120
  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20998/head:pull/20998

PR: https://git.openjdk.org/jdk/pull/20998

From liach at openjdk.org  Fri Sep 13 13:10:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 13:10:06 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`? https://github.com/openjdk/jdk/blob/f7cb6e23194c8e08a699eca84ae9b424c0283588/src/java.base/share/classes/java/lang/reflect/ParameterizedType.java#L50-L58

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348921651

From mcimadamore at openjdk.org  Fri Sep 13 13:12:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 13:12:04 GMT
Subject: RFR: 8340120: Out of bounds addressing in mismatch
In-Reply-To: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
References: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
Message-ID: <aqci_cvNIzlHDsZqO39gRAEMkcye0Rg3Myz_JsqwZx8=.a5d9d293-0a8d-4d47-b987-b4751f75f40c@github.com>

On Fri, 13 Sep 2024 13:02:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a build error where we addressed out of bounds.

Can we please add a regression test to cover it?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20998#pullrequestreview-2303088571

From prappo at openjdk.org  Fri Sep 13 13:17:03 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 13:17:03 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
 <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>
Message-ID: <k0_4bgwbhHAmOFyF128khqv5zgWdtcBdPrAQ7gYKfuw=.34dff2db-b46c-4b14-9d52-60707a014ba1@github.com>

On Fri, 13 Sep 2024 13:07:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`?

Sure, it is possible. However, there's a tradeoff between comprehensiveness and the effort required. Joe's script provides a lot for a little.

If there's interest in it, we could file follow-up bugs to fix more cases with more powerful tools.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348937038

From djelinski at openjdk.org  Fri Sep 13 13:26:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 13 Sep 2024 13:26:05 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <tlTjaZss1wHQl-SWSqFiODYdOg03NitVvUnQ6HNaFQk=.7d3d0434-3634-42fd-b7fc-3ba8704a7e7c@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303131739

From pminborg at openjdk.org  Fri Sep 13 14:02:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 14:02:04 GMT
Subject: RFR: 8340120: Remove redundant code in
 SegmentBulkOperations::mismatch
In-Reply-To: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
References: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
Message-ID: <RL3dYO5f56eCiZ2IchMCSIwMuDWdHooLrSwCCl2PMxk=.be1af228-d61f-4ece-afb5-2ec42d3d86ee@github.com>

On Fri, 13 Sep 2024 13:02:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a build error where we addressed out of bounds.

This title has been changed as this code segment was never invoked. So, we could not add a test that touches the code. Also, this will not fix any out-of-bounds addressing but will only reduce the code surface.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20998#issuecomment-2349035087

From asemenyuk at openjdk.org  Fri Sep 13 14:16:12 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Sep 2024 14:16:12 GMT
Subject: Integrated: 8334301: Errors in jpackage man page
In-Reply-To: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>
References: <UOBEWE6ichPCvDtS_3J_bLllx4j78_Z-grr4tr2KOR8=.5a783bac-ecea-42be-bd57-8da79446ff78@github.com>
Message-ID: <0KHCEY85PMImxIfxE74m6itpJH7ro78EW2QjrQ6uYnM=.abc1412a-f0f8-4af2-8c0e-328f54ea80a8@github.com>

On Thu, 12 Sep 2024 16:14:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Correct jpackage man errors

This pull request has now been integrated.

Changeset: 3c4d15bd
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c4d15bdceaf94698af99d6b6fb12b3a28e13fdf
Stats:     24 lines in 1 file changed: 10 ins; 10 del; 4 mod

8334301: Errors in jpackage man page

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/20969

From nbenalla at openjdk.org  Fri Sep 13 14:34:15 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 14:34:15 GMT
Subject: Withdrawn: 8317356: Test ClassFile API if it deals with nulls
 correctly across the whole API
In-Reply-To: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
References: <n4imaOf45FndUTDWOvyhv0S0_3CYwArhLKVMSJeyJdQ=.df92ed06-ba11-4f23-b2e4-7364f9817a0e@github.com>
Message-ID: <JVvUnbArgv5rFQmn0B0UtuJV9DwKk3hQU5y5QWiKUUo=.8537dde7-c997-4530-b4f6-d6f76ed64754@github.com>

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> The test is inspired from [FFM API's TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java), I customized their Null checking framework it to work with ClassFile API.
> 
> The framework for for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> This test reveals some inconsistencies in the ClassFile API, whether it's a method with nullable arguments`[1]`, nulls are passed to`[2]` or its implementation handles nulls `[3]` `[4]`.
> 
> 
> `[1]:` [ModuleRequireInfo#of](https://github.com/openjdk/jdk/blob/25e03b52094f46f89f2fe8f20e7e5622928add5f/src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java#L89)
> `[2]:` [Signature$ClassTypeSig#of](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/Signature.java#L150)
> `[3]:`  [CatchBuilderImpl#catching](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java#L55)
> `[4]:` [CodeBuilder#loadConstant](https://github.com/openjdk/jdk/blob/7ad61605f1669f51a97f4f263a7afaa9ab7706be/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L615)
> 
> 
> 
> `test/jdk/jdk/classfile/TestNullHostile.java#EXCLUDE_LIST` has the list of methods that are still not null hostile, they are ignored by the test, as making them null hostile either breaks some tests (listed below) or breaks the build with a `NullPointerException` or `BootstapMethodError`. I will paste the relevant methods from that list here.
> 
> Tests broken by these methods are :
> 
> 
> jdk/classfile/VerifierSelfTest.java
> jdk/classfile/TestRecordComponent.java
> jdk/classfile/TestNullHostile.java	
> jdk/classfile/OpcodesValidationTest.java
> jdk/classfile/ClassPrinterTest.java
> java/lang/invoke/MethodHandlesGeneralTest.java	
> java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
> java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java	
> java/lang/invoke/MethodHandleProxies/BasicTest.java
> 
> 
> Full list of methods
> 
> 
> //the implementation of this method in CatchBuilderImpl handles nulls, is this fine?
> "java.lang.classfile.CodeBuilder$CatchBuilder/catching(java.lang.constant.ClassDesc,java.util.function.Consumer)/0/0",
> 
> // making this method null-hostile causes a BootstapMethodError during the the build
> //        java.lang.BootstrapMethodError: bootstrap method initiali...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20556

From pminborg at openjdk.org  Fri Sep 13 14:41:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 14:41:11 GMT
Subject: Integrated: 8333843: Provide guidelines on MemorySegment to read
 strings with known lengths
In-Reply-To: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
Message-ID: <0yyXpNW5vlx6KdP_vTp_plzPUqel1l7huqnMHR6M4ic=.577fff9c-6e8d-44de-b5c1-263e0de30e9a@github.com>

On Tue, 27 Aug 2024 09:36:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.

This pull request has now been integrated.

Changeset: 3e0da58e
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e0da58ee6553fc0ed841db4a8800d50bc444517
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8333843: Provide guidelines on MemorySegment to read strings with known lengths

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/20725

From alan.bateman at oracle.com  Fri Sep 13 14:43:42 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Sep 2024 15:43:42 +0100
Subject: How many methods have been deprecated in sun.misc.Unsafe? (JEP
 471)
In-Reply-To: <CAF2POUf424DzVx=mL6BCh9n7RF8x7iC+PwXdOo3h24T4ceo7Pw@mail.gmail.com>
References: <CAF2POUf424DzVx=mL6BCh9n7RF8x7iC+PwXdOo3h24T4ceo7Pw@mail.gmail.com>
Message-ID: <b2e11aa0-03f9-4cf1-818d-ad05ce0c1bbe@oracle.com>

On 13/09/2024 10:49, Zheka Kozlov wrote:
> Hello!
>
> JEP 471 says that 79 methods out of 87 have been deprecated in 
> sun.misc.Unsafe. However, I have a different number.
>
> Deprecated for removal in Java 18:
> 1. public long objectFieldOffset(Field f)
> 2. public Object staticFieldBase(Field f)
> 3. public long staticFieldOffset(Field f)
These three were ordinarily deprecated in JDK 18, then deprecated for 
removal in JDK 23.

I didn't check the numbers, the main thing with this JEP is that it 
contains the roadmap for removal for everything except the 3 instance 
methods that you listed at the end. It's important that developers 
maintaining libraries using Unsafe are looking at VarHandle and FFM APIs.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240913/0c2f0549/attachment.htm>

From pminborg at openjdk.org  Fri Sep 13 14:46:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 14:46:09 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <n-SerjbIumSRZ58QnRyJtCXviqFOlHl7ROlK4iLGTrw=.fb21b7b0-6a09-4605-aa53-e5f51725fac1@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <n-SerjbIumSRZ58QnRyJtCXviqFOlHl7ROlK4iLGTrw=.fb21b7b0-6a09-4605-aa53-e5f51725fac1@github.com>
Message-ID: <DqvZlK_w6Iovei0l49jJf6ezEfJuc2KfxCiXrmtKd9k=.98850292-1214-45b8-a075-44244cdccc7d@github.com>

On Fri, 13 Sep 2024 12:40:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename and reformat
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 50:
> 
>> 48:     private MethodHandlesInternal() {}
>> 49: 
>> 50:     public static VarHandle findVarHandle(MethodHandles.Lookup lookup,
> 
> Do you think we should create a 3-arg overload like `Lookup lookup, String name, Class<?> type` that calls `findVarHandle(lookup, lookup.lookupClass(), name, type);` for ease of use at many call sites?

The pro: Simpler code at the call site. The con: it is a bit magic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758999490

From epeter at openjdk.org  Fri Sep 13 14:48:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 13 Sep 2024 14:48:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
Message-ID: <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>

On Fri, 6 Sep 2024 18:08:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 1048:
>> 
>>> 1046:         return SHORT_GENERATOR_SELECT_FROM_TRIPLES.stream().map(List::toArray).
>>> 1047:                 toArray(Object[][]::new);
>>> 1048:     }
>> 
>> Just a control question: does this also occasionally generate examples with out-of-bounds indices? Negative out of bounds and positive out of bounds?
>
> Original API did throw IndexOutOfBoundsException, but later on we have moved away from exception throwing semantics to wrapping semantics.
> Please find details at following comment
> https://github.com/openjdk/jdk/pull/20508#issuecomment-2306344606

And do we test that the wrapping works correctly?

>> test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 5812:
>> 
>>> 5810:                 ShortVector bv = ShortVector.fromArray(SPECIES, b, i);
>>> 5811:                 ShortVector idxv = ShortVector.fromArray(SPECIES, idx, i);
>>> 5812:                 idxv.selectFrom(av, bv).intoArray(r, i);
>> 
>> Would this test catch a bug where the backend would generate vectors that are too long or too short?
>
> Existing vectorAPI inline expansion entry points explicitly pass lane type and count as intrinsic arguments, this is used to create concrete ideal vector types.

That does not answer my question. If the backend operations you implemented would have the wrong vector-length: do we have any tests that would catch that? Often that requires not just going "up" with a loop but also "counting down" with the loop iv. Do you know what I mean?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1758999902
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1759002531

From epeter at openjdk.org  Fri Sep 13 14:52:11 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 13 Sep 2024 14:52:11 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <7bghGF2-qbhP1hJA2ljtdA3xSUSqiV0RLaOYm4AcZSQ=.eb3e36b2-5461-4755-ae71-2de89660649f@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <7bghGF2-qbhP1hJA2ljtdA3xSUSqiV0RLaOYm4AcZSQ=.eb3e36b2-5461-4755-ae71-2de89660649f@github.com>
Message-ID: <SYac8lqYykI_Clh7VMxU4dh3mrW1aEBCLidCqo0MTjo=.7aa5a12c-4eef-46d0-8112-20057e715215@github.com>

On Tue, 3 Sep 2024 11:45:53 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding descriptive comments
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 544:
> 
>> 542:         byte[] vpayload1 = ((ByteVector)v1).vec();
>> 543:         byte[] vpayload2 = ((ByteVector)v2).vec();
>> 544:         byte[] vpayload3 = ((ByteVector)v3).vec();
> 
> Is there a reason you are not using more descriptive names here instead of `vpayload1`?
> I also wonder if the `selectFromHelper` should not be named more specifically: `selectFromTwoVector(s)Helper`?

You only gave me a thumbs up and no change - but comment resolved. Is that intentional? Makes me feel like you are ignoring my comments, and that discourages me from reviewing in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1759008094

From epeter at openjdk.org  Fri Sep 13 14:56:10 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 13 Sep 2024 14:56:10 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v8]
In-Reply-To: <yQY-Q1-MIRyJmsvqMsSNXabjOX2pDMnZwIAOCd4VFK8=.a0634119-4f6f-4e54-88d0-0a6859167537@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <yQY-Q1-MIRyJmsvqMsSNXabjOX2pDMnZwIAOCd4VFK8=.a0634119-4f6f-4e54-88d0-0a6859167537@github.com>
Message-ID: <sEBLsCrcvAsikebe_6UB9Hh3G73tCtyeoyi6BXMIcQc=.66803327-4010-4ab2-8d18-cf2802f8f606@github.com>

On Fri, 6 Sep 2024 18:13:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review resolutions.

Can you please **define** somewhere what it means to `prune indexes`? It does not help me much more than the previous "massaging indexes" you had before I asked you to change it.

> Also: I'm a little worried about the semantics change of the RearrangeNode that you did with the changes in RearrangeNode::Ideal. It looks a little "hacky", especially in conjunction with the vector_indexes_needs_massaging method. Can you give a clear definition of the semantics of RearrangeNode and vector_indexes_needs_massaging, please?

You have also not responded to this yet. It seems to me that before your proposed change, `RearrangeNode` had a clear and easy semantic, and now you somehow "hack it" to work with your `vector_indexes_needs_pruning`. Can you explain please why this makes sense and add a comment to `RearrangeNode` what its semantics is?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2349148857

From nbenalla at openjdk.org  Fri Sep 13 15:08:33 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 15:08:33 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
Message-ID: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>

Could I get a review for this small change?
The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.

TIA

-------------

Commit messages:
 - Broken link to the dieharder distribution website in SplittableRandom

Changes: https://git.openjdk.org/jdk/pull/21000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339847
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21000/head:pull/21000

PR: https://git.openjdk.org/jdk/pull/21000

From iris at openjdk.org  Fri Sep 13 15:19:05 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Sep 2024 15:19:05 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <Q3uvTdeYAD6lQr1uHLqqd8-toTUlyRqNyLwoyhbuWpE=.448f7d38-6d1d-4dcd-828d-9af55b6464f6@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

Confirmed.  New link appears to be correct.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21000#pullrequestreview-2303413572

From mcimadamore at openjdk.org  Fri Sep 13 15:20:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 15:20:04 GMT
Subject: RFR: 8340120: Remove redundant code in
 SegmentBulkOperations::mismatch
In-Reply-To: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
References: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
Message-ID: <InkfhdFKJWoRt-oZzmtCGUJtoie1SJ3hARCAS2nwPz0=.25fedc30-f56c-4315-8de7-41775e79810e@github.com>

On Fri, 13 Sep 2024 13:02:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a build error where we addressed out of bounds.

I am now convinced that this was just about dead code - please mark the JBS issue as `noreg-hard`.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20998#pullrequestreview-2303412796

From mcimadamore at openjdk.org  Fri Sep 13 15:20:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Sep 2024 15:20:05 GMT
Subject: RFR: 8340120: Remove redundant code in
 SegmentBulkOperations::mismatch
In-Reply-To: <RL3dYO5f56eCiZ2IchMCSIwMuDWdHooLrSwCCl2PMxk=.be1af228-d61f-4ece-afb5-2ec42d3d86ee@github.com>
References: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
 <RL3dYO5f56eCiZ2IchMCSIwMuDWdHooLrSwCCl2PMxk=.be1af228-d61f-4ece-afb5-2ec42d3d86ee@github.com>
Message-ID: <-faDKipvAt61BMQjoCtwHMHT0xCqpo5_59tobz5oveI=.e935b6e5-7628-4ad4-bf47-1a81a92056d1@github.com>

On Fri, 13 Sep 2024 13:59:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This title has been changed as this code segment was never invoked. So, we could not add a test that touches the code. Also, this will not fix any out-of-bounds addressing but will only reduce the code surface.

To be clear for future readers: the above comment is not true - the optimized versions of fill/copy/mismatch do *not* attempt to access segments outside of their spatial bounds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20998#issuecomment-2349201363

From pminborg at openjdk.org  Fri Sep 13 15:31:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 15:31:10 GMT
Subject: Integrated: 8340120: Remove redundant code in
 SegmentBulkOperations::mismatch
In-Reply-To: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
References: <TPGFdJGFTRdxe3ihI5Au4JP8qeNFhIQiq6TeUL3dxPA=.2bfb4680-ed0e-436d-bc19-b3e178884245@github.com>
Message-ID: <U1-7vqbrBdAXC4jM80b6G1DHWQDt8gmhbqlskueRG9o=.b9b01f0c-f497-4c81-8361-8b27404a056c@github.com>

On Fri, 13 Sep 2024 13:02:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR removes redundant code.

This pull request has now been integrated.

Changeset: 1a0a5388
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a0a53883f7c6f523b5fefb722e137258d527362
Stats:     9 lines in 1 file changed: 0 ins; 9 del; 0 mod

8340120: Remove redundant code in SegmentBulkOperations::mismatch

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/20998

From nbenalla at openjdk.org  Fri Sep 13 15:37:05 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 15:37:05 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <ZyJf5CVF6MeF97-77B5nhHz9L9eQ7AldPcG8R4oUhK4=.05a8d93c-cdfc-44a7-becb-b4e42428c449@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

I think this counts as "trivial" change and can be integrated without waiting for 24, if you agree Iris

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21000#issuecomment-2349235346

From duke at openjdk.org  Fri Sep 13 15:37:05 2024
From: duke at openjdk.org (duke)
Date: Fri, 13 Sep 2024 15:37:05 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <r5RixuyLK9OvvB2tlm9JQvQZWTeCtbV9zip3eHtBfLY=.10ce5167-0d95-4cf6-8ca3-92b3617c09a7@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

@nizarbenalla 
Your change (at version f7cead81b09d392d673bffa8412bbc34b69f6079) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21000#issuecomment-2349237370

From redestad at openjdk.org  Fri Sep 13 15:46:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 13 Sep 2024 15:46:35 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set
Message-ID: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>

Simple internal refactor to load a few classes less on startup. Arguably cleaner.

-------------

Commit messages:
 - Refactor makeHiddenClassDefiner to take ClassOption ...

Changes: https://git.openjdk.org/jdk/pull/21002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340131
  Stats: 19 lines in 6 files changed: 3 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21002/head:pull/21002

PR: https://git.openjdk.org/jdk/pull/21002

From jvernee at openjdk.org  Fri Sep 13 16:02:05 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Sep 2024 16:02:05 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <zPF2aHJ6nsqBockMSKZGrMGRgcq72BIyBB0JnEr_90Y=.47c1fbf7-6228-4a85-b827-ab61d3c62c20@github.com>

On Fri, 13 Sep 2024 15:40:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple internal refactor to load a few classes less on startup. Arguably cleaner.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2223:

> 2221:             }
> 2222: 
> 2223:             return makeHiddenClassDefiner(bytes.clone(), false, options.clone())

Why do we need to clone here, but not for the method above? `makeHiddenClassDefiner` seems to always turn the options in flags right away, so I don't think we need to clone?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759113533

From dfuchs at openjdk.org  Fri Sep 13 16:11:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:11:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
Message-ID: <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>

On Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Moved to `NTLMAuthentication` static initializer. 853d349
>
> @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load?

hmm...  I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759124071

From dfuchs at openjdk.org  Fri Sep 13 16:11:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:11:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
Message-ID: <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>

On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load?
>
> hmm...  I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication.

I wonder - do you see any failure if you don't load libnet from there?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759125047

From bpb at openjdk.org  Fri Sep 13 16:11:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:11:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
Message-ID: <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>

On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> hmm...  I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication.
>
> I wonder - do you see any failure if you don't load libnet from there?

Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759128167

From bpb at openjdk.org  Fri Sep 13 16:15:16 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:15:16 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
Message-ID: <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>

On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I wonder - do you see any failure if you don't load libnet from there?
>
> Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`.

> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication.

In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759132986

From liach at openjdk.org  Fri Sep 13 16:19:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 16:19:05 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <9J4Z6SxksEawr0nyRh0QhR6smFuA2JadX9u5UcG4Y4I=.3eda12f5-02df-4afd-95e8-51232116833f@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

Marked as reviewed by liach (Reviewer).

Requesting @rgiulietti to sanity check before integration.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21000#pullrequestreview-2303527622
PR Comment: https://git.openjdk.org/jdk/pull/21000#issuecomment-2349317670

From jbhateja at openjdk.org  Fri Sep 13 16:20:28 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 16:20:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v10]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <KMPrHf1coga5JNG_Lfz3ync1tWLIFWj6IQ0Qf4r4cfU=.763eebab-9a4b-4a67-bbb1-dcebcff4adb0@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Documentation change suggerstion from Paul

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/4a93042b..4301c817

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=08-09

  Stats: 343 lines in 2 files changed: 173 ins; 8 del; 162 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From naoto at openjdk.org  Fri Sep 13 16:29:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Sep 2024 16:29:05 GMT
Subject: RFR: 8339769: Incorrect error message during startup if working
 directory does not exist [v2]
In-Reply-To: <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
Message-ID: <bSwGNC5OjO1KQbt1k3QJI_XyroXmDaIzkWFCJpVcRqQ=.14145c3e-2e8c-4cf6-97a2-464d77685b92@github.com>

On Thu, 12 Sep 2024 23:11:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return null in exception site instead

LGTM.

src/java.base/unix/native/libjava/java_props_md.c line 524:

> 522:         char buf[MAXPATHLEN];
> 523:         errno = 0;
> 524:         if (getcwd(buf, sizeof(buf))  == NULL) {

Suggestion:

        if (getcwd(buf, sizeof(buf)) == NULL) {

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20975#pullrequestreview-2303545874
PR Review Comment: https://git.openjdk.org/jdk/pull/20975#discussion_r1759149656

From dfuchs at openjdk.org  Fri Sep 13 16:34:08 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:34:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
Message-ID: <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF6285gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>

On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`.
>
>> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication.
> 
> In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`.

Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759158214

From jlu at openjdk.org  Fri Sep 13 16:36:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Sep 2024 16:36:08 GMT
Subject: RFR: 8339769: Incorrect error message during startup if working
 directory does not exist [v2]
In-Reply-To: <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
Message-ID: <nTzFeL6RHMMU8LgAHkzZz5RvZHzzEdVUvC2UgTlzZm8=.cd51291a-1016-4d79-95c4-0339883bbd34@github.com>

On Thu, 12 Sep 2024 23:11:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return null in exception site instead

> Curiously in the Windows implementation of `GetJavaProperties(...)` in `java_props_md.c` in case of a failure to get the current working directory, we seem to just skip setting the working directory and don't raise any error:
> 
> ```c
> /* Current directory */
> {
>     WCHAR buf[MAX_PATH];
>     if (GetCurrentDirectoryW(sizeof(buf)/sizeof(WCHAR), buf) != 0)
>         sprops.user_dir = _wcsdup(buf);
> }
> ```

Hi Jai,

I noticed that too. I tried to replicate this scenario on Windows and was always prevented from deleting the directory that I was currently in: _The process cannot access the file because it is being used by another process._

But I'm sure there are ways to get the working directory deleted that I am unaware of. To make this fix more complete, I can add similar behavior where an exception is thrown for Windows if `GetCurrentDirectoryW` fails. AFAICT this would be correcting a faulty error message with a proper one, and so there is no behavioral change. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20975#issuecomment-2349354516

From rgiulietti at openjdk.org  Fri Sep 13 16:37:07 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Sep 2024 16:37:07 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <HCQZ0Gu2M0FCGWD1jaMsr66YsfIBXIz7xrjS3Vvtrc8=.2d79998d-5efe-4fd3-aa02-630c1b177647@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

Looks good

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21000#issuecomment-2349355875

From naoto at openjdk.org  Fri Sep 13 16:38:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Sep 2024 16:38:09 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <0fjq3uhnar6RlEAQ2heD004puGip3pLT9_0_t2Pb2hY=.c53994c7-c392-432b-8352-b9c808622d13@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

`java.nio.charset` and `java.time.format` changes look good

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303567979

From darcy at openjdk.org  Fri Sep 13 16:38:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 16:38:10 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <k0_4bgwbhHAmOFyF128khqv5zgWdtcBdPrAQ7gYKfuw=.34dff2db-b46c-4b14-9d52-60707a014ba1@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
 <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>
 <k0_4bgwbhHAmOFyF128khqv5zgWdtcBdPrAQ7gYKfuw=.34dff2db-b46c-4b14-9d52-60707a014ba1@github.com>
Message-ID: <Np2yuYhE4jr_QNisqtxC3fG6UPpCMu_a_N3MXAY18RQ=.65f78625-2365-4f7d-8d9a-b15f6a24d310@github.com>

On Fri, 13 Sep 2024 13:13:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`?
> 
> Sure, it is possible. However, there's a tradeoff between comprehensiveness and the effort required. Joe's script provides a lot for a little.
> 
> If there's interest in it, we could file follow-up bugs to fix more cases with more powerful tools.

Yes, the quick and dirty program is only a "minimum viable product" level of functionality. It is not complete and doesn't catch all cases. Future improvements welcome!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2349358796

From bpb at openjdk.org  Fri Sep 13 16:38:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:38:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF6285gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
 <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF628
 5gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
Message-ID: <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>

On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication.
>> 
>> In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`.
>
> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM.

I would have to check. The failure I observed occurred in both of these tests

test/jdk/sun/net/www/protocol/http/NoNTLM.java
test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java

and nowhere else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759166801

From jlu at openjdk.org  Fri Sep 13 16:41:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Sep 2024 16:41:40 GMT
Subject: RFR: 8339769: Incorrect error message during startup if working
 directory does not exist [v3]
In-Reply-To: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
Message-ID: <SPEk1zMMPaVDEmZgLc4Cu7F9p7Zwb-klxXKXvSrIhJg=.1e640932-abe0-4aa1-b7bb-f9b6a99399a4@github.com>

> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
> 
> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
> 
> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
> 
> 
>     // Get the platform specific values
>     sprops = GetJavaProperties(env);
>     CHECK_NULL_RETURN(sprops, NULL);
> 
> 
> Testing done locally on both platforms.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  fix bad spacing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20975/files
  - new: https://git.openjdk.org/jdk/pull/20975/files/c69216ee..6332bb96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20975&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20975&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20975/head:pull/20975

PR: https://git.openjdk.org/jdk/pull/20975

From jpai at openjdk.org  Fri Sep 13 16:41:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Sep 2024 16:41:40 GMT
Subject: RFR: 8339769: Incorrect error message during startup if working
 directory does not exist [v2]
In-Reply-To: <nTzFeL6RHMMU8LgAHkzZz5RvZHzzEdVUvC2UgTlzZm8=.cd51291a-1016-4d79-95c4-0339883bbd34@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <vjx2E-GXTZr3eCeUPjO6H0O97UTaK_Kt8ZBa3EdR-5c=.c150a370-a54e-4624-9723-01ab17e28742@github.com>
 <nTzFeL6RHMMU8LgAHkzZz5RvZHzzEdVUvC2UgTlzZm8=.cd51291a-1016-4d79-95c4-0339883bbd34@github.com>
Message-ID: <ZfdvRCI7Sm8GWdgWWf8k9_X8dbewlDNlsnKCSN4OTU4=.4c8217fb-dae5-4eff-9ac9-a4d0ed071dcc@github.com>

On Fri, 13 Sep 2024 16:33:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> AFAICT this would be correcting a faulty error message with a proper one, and so there is no behavioral change. What do you think?

Hello Justin, for this current PR, I think it's OK to just go ahead with the current changes that you have for Linux and macos. The Windows one I think can be investigated separately to understand if any similar change is needed and what impact it could have. I merely brought it up because I found it odd compared to what we do in these other platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20975#issuecomment-2349367889

From psandoz at openjdk.org  Fri Sep 13 16:46:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 13 Sep 2024 16:46:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
Message-ID: <z3EbMS9-xK-UWH7YRhDniyj9jchDKoZcCX5v1JaHejk=.afb955f9-d2c3-4627-a62a-b4bdd29c56cb@github.com>

On Fri, 6 Sep 2024 18:08:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 2770:
>> 
>>> 2768: 
>>> 2769:     /**
>>> 2770:      * Rearranges the lane elements of two vectors, selecting lanes
>> 
>> I have a bit of a name concern here. Why are we calling it "select" and not "rearrange"? Because for a single "from" vector we also call it "rearrange", right? Is "select" not often synonymous to "blend", which works also with two "from" vectors, but with a mask and not indexing for "selection/rearranging"?
>
> We already have another flavor of [selectFrom](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html#selectFrom(jdk.incubator.vector.Vector)) which permutes single vector, new API extents its semantics to two vector selection, so we kept the nomenclature consistent.

Select operates only on vectors where the `this` vector represents the indexes to *select* elements from the other vectors. Rearrange operates on vectors and a shuffle argument that *rearranges* elements from the other vectors. The former behavior can be specified in terms of the latter behavior, and ideally the equivalent expressions should result in ~same generated sequence of instructions. However, we are not there yet and need to further optimize shuffles to make that happen. But, we can optimize `selectFrom` with the dependent change to wrap indexes instead of throwing when out of bounds.

(Separately there is an annoying issue with select, that we should not address in this PR. Using a Float/Double Vector for indexes is awkward.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1759182233

From dfuchs at openjdk.org  Fri Sep 13 16:48:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:48:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
 <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF628
 5gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
 <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>
Message-ID: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com>

On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM.
>
> I would have to check. The failure I observed occurred in both of these tests
> 
> test/jdk/sun/net/www/protocol/http/NoNTLM.java
> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
> 
> and nowhere else.

I see. The test does:

            Class<?> ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader());

so that explains it.

In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly.

What you have is good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759183851

From liach at openjdk.org  Fri Sep 13 16:52:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 16:52:08 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <3pXE4pv6hyvGSEe1JBp2R6CchhZvSKzjKol3UVdPkRI=.983e0a29-3ac0-4682-a4a5-e5fb17a0ed85@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Looks good. It might be feasible to run a more complex tool that analyzes the tokenized javadoc AST from javac as later work.

Annotation changes look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303605703

From darcy at openjdk.org  Fri Sep 13 16:52:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 16:52:09 GMT
Subject: Integrated: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <J8BfJJeKKhzF2epyfIx0mPVlrNhMBe9dtJvRcfgHbjo=.5796e5bd-88db-4421-b542-8a251394c8cf@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

This pull request has now been integrated.

Changeset: 89c172ac
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89c172ac47a9cc238739338417015bf912ad5424
Stats:     59 lines in 21 files changed: 0 ins; 27 del; 32 mod

8340082: Use inline return tag in java.base

Reviewed-by: iris, prappo, lancea, djelinski, naoto, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20981

From liach at openjdk.org  Fri Sep 13 16:59:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 16:59:09 GMT
Subject: RFR: 8339847: Broken link to the dieharder distribution website in
 SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <gNYI3tXgFCaLkND_ZZovbQ-APukWWLGLcKWe3kiRuUI=.e567be14-cf0c-4657-baa5-2d58076ee6b0@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

Thanks Raffaello for the confirmation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21000#issuecomment-2349418527

From nbenalla at openjdk.org  Fri Sep 13 16:59:09 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 13 Sep 2024 16:59:09 GMT
Subject: Integrated: 8339847: Broken link to the dieharder distribution website
 in SplittableRandom
In-Reply-To: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
References: <bkMxAqNbg9AWv7c9Yf9KGkCMHYjgjTtf61dDKcOFS0g=.93fe4557-1bf0-48ea-8b72-d818b6d26fd8@github.com>
Message-ID: <3YKLIiAAro-cilWqX3USCf8YbGTkj1YMC9Aza2EqOQs=.6127f1c6-9e0f-4664-a9d4-b0ea2476e464@github.com>

On Fri, 13 Sep 2024 14:48:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Could I get a review for this small change?
> The page linked in `SplittableRandom` was moved at some point, this change points to the correct page to avoid redirects.
> 
> TIA

This pull request has now been integrated.

Changeset: 37bf589e
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37bf589ec087c80851abb9d35910f09850cea9f6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8339847: Broken link to the dieharder distribution website in SplittableRandom

Reviewed-by: iris, liach

-------------

PR: https://git.openjdk.org/jdk/pull/21000

From bpb at openjdk.org  Fri Sep 13 17:06:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 17:06:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
 <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF628
 5gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
 <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>
 <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com>
Message-ID: <0IMOcZubegYzX-gY4eVUoKl6dSj4FUUkLVO6zYwhTxU=.e0d23617-85fb-4075-be9a-b245205497df@github.com>

On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I would have to check. The failure I observed occurred in both of these tests
>> 
>> test/jdk/sun/net/www/protocol/http/NoNTLM.java
>> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
>> 
>> and nowhere else.
>
> I see. The test does:
> 
>             Class<?> ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader());
> 
> so that explains it.
> 
> In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly.
> 
> What you have is good to me.

Good! Thanks for the assistance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759204325

From liach at openjdk.org  Fri Sep 13 17:08:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 17:08:07 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v3]
In-Reply-To: <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>
Message-ID: <zLIKQWEc8LxyMoj5ZYuc8c4zUqekH8-TCHe5mxhtB2s=.30878ccf-0b45-4807-9dd5-edf52bf81694@github.com>

On Sat, 7 Sep 2024 08:51:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce JDKUTF#utflen codeSize

src/java.base/share/classes/java/io/ObjectOutputStream.java line 2014:

> 2012:         }
> 2013: 
> 2014:         void writeUTF(String str, int stroff) throws IOException {

Can we move this to be near `writeUTFInternal` and make this `private` as they are closely related? This should also be renamed to indicate this is internal, like `writeMoreUtf` to avoid misuse.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 182:

> 180: 
> 181:         for (int i = countNonZeroAscii; i < strlen;) {
> 182:             offset = JDKUTF.putChar(elems, offset, str.charAt(i++));

Can we put this `++` in for loop instead of the statement here?

src/java.base/share/classes/jdk/internal/util/JDKUTF.java line 35:

> 33:  * @since 24
> 34:  */
> 35: public abstract class JDKUTF {

Can we name this class `ModifiedUtf`? `JDKUTF` looks like a constant field name, and this format is part of Java Platform instead of just JDK.

src/java.base/share/classes/jdk/internal/util/JDKUTF.java line 37:

> 35: public abstract class JDKUTF {
> 36:     @ForceInline
> 37:     public static int putChar(byte[] buf, int offset, char c) {

Do you think we can just move the loop here, like:

public static int putChars(byte[] buf, int offset, String str, int strStart, int strEnd) {
    for (int i = strStart; i < strEnd; i++) {
        offset = putChar(buf, offset, str.charAt(i);
    }
}

We can even unroll putChar in the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1759191218
PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1759175406
PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1759172395
PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1759205885

From swen at openjdk.org  Fri Sep 13 17:14:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 13 Sep 2024 17:14:17 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v5]
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <lV-6mY29s_6WZf-nYH6SyWbshj24wMaTnd9g4TFQtoA=.f93efaea-c3d6-498c-a355-93a6719eb4c0@github.com>

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge remote-tracking branch 'upstream/master' into optim_classfile_loadconstant_2020408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
 - Merge remote-tracking branch 'upstream/master' into optim_classfile_loadconstant_2020408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
 - comments
 - fix comment
 - since 24
 - optimize loadConstant

-------------

Changes: https://git.openjdk.org/jdk/pull/20761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=04
  Stats: 86 lines in 2 files changed: 59 ins; 22 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20761/head:pull/20761

PR: https://git.openjdk.org/jdk/pull/20761

From qamai at openjdk.org  Fri Sep 13 17:23:05 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 13 Sep 2024 17:23:05 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <L3raQIsBWTc504BaXOu5vM0JbmlPKywyLzbbb6mD8dg=.88612fb2-b53a-4a1b-9538-daaeaca66d9d@github.com>

On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

Given `rearrange` with 1 vector gets wrapping indices semantics. I think we should stop normalizing indices when converting a `Vector` into a `VectorShuffle` (currently we wrap all out-of-bound elements to `[-VLEN, 0)`). Then the rearrange with 2 vectors will also wrap similarly (all indices are `& (VLEN * 2 - 1)`, then indices `[0, VLEN)` maps to the first vector and indices `[VLEN, 2 * VLEN)` map to the second vector). What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2349535266

From jbhateja at openjdk.org  Fri Sep 13 17:31:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 17:31:24 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <aqBblQCYrW4fItjHak45eHoINlpw0pkOWuylqGpgAJY=.9bdd44e2-493b-4b04-98c3-7be4e96736ca@github.com>

On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

src/hotspot/share/opto/vectorIntrinsics.cpp line 2206:

> 2204:   const Type * byte_bt = Type::get_const_basic_type(T_BYTE);
> 2205:   const TypeVect * byte_vt  = TypeVect::make(byte_bt, num_elem);
> 2206:   Node* byte_shuffle = gvn().transform(VectorCastNode::make(cast_vopc, v1, T_BYTE, num_elem));

We can be optimal here and prevent down casting and subsequent load shuffles in applicable scenarios, e.g. indexes held in integral vectors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1758203424

From swen at openjdk.org  Fri Sep 13 17:38:56 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 13 Sep 2024 17:38:56 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v4]
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <Wn4WnQbybWxflM6QmBKikEvyyO2-pYCnJKJ3gOXd1rg=.41c6ce91-27d9-48e4-93e8-dae491aef4d1@github.com>

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - rename JDKUTF to ModifiedUtf
 - suggestion from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20886/files
  - new: https://git.openjdk.org/jdk/pull/20886/files/9744e8a5..58a23d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=02-03

  Stats: 47 lines in 4 files changed: 21 ins; 15 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20886/head:pull/20886

PR: https://git.openjdk.org/jdk/pull/20886

From swen at openjdk.org  Fri Sep 13 17:38:56 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 13 Sep 2024 17:38:56 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v3]
In-Reply-To: <zLIKQWEc8LxyMoj5ZYuc8c4zUqekH8-TCHe5mxhtB2s=.30878ccf-0b45-4807-9dd5-edf52bf81694@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <lzv4p51BYGHYHhOBmcjHP-6hrpZRx00RYVeodGZMUKY=.4cbb4907-1553-4c9d-bc07-f1e8acba058a@github.com>
 <zLIKQWEc8LxyMoj5ZYuc8c4zUqekH8-TCHe5mxhtB2s=.30878ccf-0b45-4807-9dd5-edf52bf81694@github.com>
Message-ID: <5nl8DUdbw9C9mvUOqC_Wg1Qk8PfUhlftSgvNUdLoMEw=.6ab2256f-bc47-47fe-9e4a-ae440a8f0d01@github.com>

On Fri, 13 Sep 2024 17:05:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce JDKUTF#utflen codeSize
>
> src/java.base/share/classes/jdk/internal/util/JDKUTF.java line 37:
> 
>> 35: public abstract class JDKUTF {
>> 36:     @ForceInline
>> 37:     public static int putChar(byte[] buf, int offset, char c) {
> 
> Do you think we can just move the loop here, like:
> 
> public static int putChars(byte[] buf, int offset, String str, int strStart, int strEnd) {
>     for (int i = strStart; i < strEnd; i++) {
>         offset = putChar(buf, offset, str.charAt(i);
>     }
> }
> 
> We can even unroll putChar in the loop.

This does not work in ObjectOutputStream#writeMoreUTF

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1759243420

From jbhateja at openjdk.org  Fri Sep 13 17:41:08 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 17:41:08 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
 <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>
Message-ID: <O757o3aig_rEnL3ZedwJwXrol51JVmGQKAMLFtiYjtU=.671debb0-d536-4e8b-93d6-f23d4f3fd48b@github.com>

On Fri, 13 Sep 2024 14:45:29 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Existing vectorAPI inline expansion entry points explicitly pass lane type and count as intrinsic arguments, this is used to create concrete ideal vector types.
>
> That does not answer my question. If the backend operations you implemented would have the wrong vector-length: do we have any tests that would catch that? Often that requires not just going "up" with a loop but also "counting down" with the loop iv. Do you know what I mean?

Patch includes tests for all the species (combination of vector type and sizes), each vector kernel is validated against equivalent scalar implementation, scenario which you are referring is implicitly handled though tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1759246223

From sviswanathan at openjdk.org  Fri Sep 13 18:20:07 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Sep 2024 18:20:07 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <L3raQIsBWTc504BaXOu5vM0JbmlPKywyLzbbb6mD8dg=.88612fb2-b53a-4a1b-9538-daaeaca66d9d@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <L3raQIsBWTc504BaXOu5vM0JbmlPKywyLzbbb6mD8dg=.88612fb2-b53a-4a1b-9538-daaeaca66d9d@github.com>
Message-ID: <gFiugusEK31pCIqMQgnlNSGQLhykQjPBbUoxzLcGpG8=.a5a333b3-44a5-4657-b9f9-3d7f51d6229a@github.com>

On Fri, 13 Sep 2024 17:20:40 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Given `rearrange` with 1 vector gets wrapping indices semantics. I think we should stop normalizing indices when converting a `Vector` into a `VectorShuffle` (currently we wrap all out-of-bound elements to `[-VLEN, 0)`). Then the rearrange with 2 vectors will also wrap similarly (all indices are `& (VLEN * 2 - 1)`, then indices `[0, VLEN)` maps to the first vector and indices `[VLEN, 2 * VLEN)` map to the second vector). We will normalize the indices when we invoke `VectorShuffle::toVector` which I think is much less used than `Vector::toShuffle`. What do you think?

The guidance from Paul Sandoz and John Rose is to keep the the partial wrapping at shuffle construction as is for now and only change the rearrange and selectFrom apis.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2349763832

From sviswanathan at openjdk.org  Fri Sep 13 18:27:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Sep 2024 18:27:06 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <aqBblQCYrW4fItjHak45eHoINlpw0pkOWuylqGpgAJY=.9bdd44e2-493b-4b04-98c3-7be4e96736ca@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <aqBblQCYrW4fItjHak45eHoINlpw0pkOWuylqGpgAJY=.9bdd44e2-493b-4b04-98c3-7be4e96736ca@github.com>
Message-ID: <aKDb17oHvlaJb87VFKyg4VfrTv99EFC31LQwSdNYA7o=.762420cc-cfc6-45a9-9307-0ce24bb6eff9@github.com>

On Fri, 13 Sep 2024 05:30:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>> 
>> Summary of changes is as follows:
>>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>> 
>> For the following source:
>> 
>> 
>>     public void test() {
>>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>>             index.selectFrom(inpvect).intoArray(byteres, j);
>>         }
>>     }
>> 
>> 
>> The code generated for inner main now looks as follows:
>> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>>   0x00007f40d02274d0:   movslq %ebx,%r13
>>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>>   0x00007f40d022751f:   add    $0x40,%ebx
>>   0x00007f40d0227522:   cmp    %r8d,%ebx
>>   0x00007f40d0227525:   jl     0x00007f40d02274d0
>> 
>> Best Regards,
>> Sandhya
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2206:
> 
>> 2204:   const Type * byte_bt = Type::get_const_basic_type(T_BYTE);
>> 2205:   const TypeVect * byte_vt  = TypeVect::make(byte_bt, num_elem);
>> 2206:   Node* byte_shuffle = gvn().transform(VectorCastNode::make(cast_vopc, v1, T_BYTE, num_elem));
> 
> We can be optimal here and prevent down casting and subsequent load shuffles in applicable scenarios, e.g. indexes held in integral vectors.

@jatin-bhateja If you could expand on this comment with specific cases it will be helpful. The loadShuffle generation is needed for platform specific handling of shuffles and cannot be optimized out here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759296031

From jbhateja at openjdk.org  Fri Sep 13 18:30:08 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 18:30:08 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v8]
In-Reply-To: <sEBLsCrcvAsikebe_6UB9Hh3G73tCtyeoyi6BXMIcQc=.66803327-4010-4ab2-8d18-cf2802f8f606@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <yQY-Q1-MIRyJmsvqMsSNXabjOX2pDMnZwIAOCd4VFK8=.a0634119-4f6f-4e54-88d0-0a6859167537@github.com>
 <sEBLsCrcvAsikebe_6UB9Hh3G73tCtyeoyi6BXMIcQc=.66803327-4010-4ab2-8d18-cf2802f8f606@github.com>
Message-ID: <ZZ2O3vCMVfqBhHvt19K-yy37ekoBDc5NskzH1snNPpY=.11db448d-8342-4f33-9976-da7976085e95@github.com>

On Fri, 13 Sep 2024 14:53:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Can you please **define** somewhere what it means to `prune indexes`? It does not help me much more than the previous "massaging indexes" you had before I asked you to change it.
> 
> > Also: I'm a little worried about the semantics change of the RearrangeNode that you did with the changes in RearrangeNode::Ideal. It looks a little "hacky", especially in conjunction with the vector_indexes_needs_massaging method. Can you give a clear definition of the semantics of RearrangeNode and vector_indexes_needs_massaging, please?
> 
> You have also not responded to this yet. It seems to me that before your proposed change, `RearrangeNode` had a clear and easy semantic, and now you somehow "hack it" to work with your `vector_indexes_needs_pruning`. Can you explain please why this makes sense and add a comment to `RearrangeNode` what its semantics is?

In case target does not directly support two vector selection instruction we lower the IR to its constituents, this is better than  intrinsification failure as it saves costly vector boxing penalties. 

Think in terms of desired compiler IR and not rearrange API semantics,  VectorRearrange IR node always expects a shape conformance b/w vector to be permuted and index vector, since shuffle indices are held in byte array based backing storage hence compiler injects VectorLoadShuffle nodes to upcast the byte vector lanes holding indexes to match the input vector lane. 
Since selectFrom API already passes the indexes through vector hence we can save emitting redundant toShuffle() + toVector() operations in all cases apart from some target specific scenarios e.g. AVX2 targets [do not support direct short vector permute]instruction "VPERMW", hence we need to [massage the index vector](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L8771) to emulate desired permutation using byte permute instruction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2349801299

From duke at openjdk.org  Fri Sep 13 18:36:08 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 13 Sep 2024 18:36:08 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <PQL6lFkvhPBP4U_C2k7jCeXKYXS7ZMV-OFeRbEbl4Xs=.0560f11a-dfb1-4acc-931e-bdef1425ddeb@github.com>

On Fri, 13 Sep 2024 15:40:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple internal refactor to load a few classes less on startup. Arguably cleaner.

The?private?methods don?t?need to?be?`ACC_VARARGS`, also?remove excess?whitespace between?`ClassOption` and?`...` to?match the?code?style of?the?rest of?the?JDK.

Also, it?might be?a?good?idea to?add?overloads which?don?t?take any?options to?avoid unnecessary?allocation of?zero?length?arrays, such?as?those in?`InvokerBytecodeGenerator`, `MethodHandleProxies`, and?`StringConcatFactory`.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 80:

> 78:     private static final boolean disableEagerInitialization;
> 79: 
> 80:     public static final MethodHandles.Lookup.ClassOption[] LAMBDA_CLASS_OPTIONS = { NESTMATE, STRONG };

Suggestion:

    private static final MethodHandles.Lookup.ClassOption[] LAMBDA_CLASS_OPTIONS = { NESTMATE, STRONG };

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 1909:

> 1907:             }
> 1908: 
> 1909:             static int optionsToFlag(ClassOption ... options) {

Suggestion:

            static int optionsToFlag(ClassOption[] options) {

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2390:

> 2388:         private ClassDefiner makeHiddenClassDefiner(byte[] bytes,
> 2389:                                                     boolean accessVmAnnotations,
> 2390:                                                     ClassOption ... options) {

Suggestion:

                                                    ClassOption[] options) {

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2405:

> 2403:          * @return ClassDefiner that defines a hidden class of the given bytes and options.
> 2404:          */
> 2405:         ClassDefiner makeHiddenClassDefiner(String name, byte[] bytes, ClassFileDumper dumper, ClassOption ... options) {

Suggestion:

        ClassDefiner makeHiddenClassDefiner(String name, byte[] bytes, ClassFileDumper dumper, ClassOption... options) {

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2423:

> 2421:                                                     boolean accessVmAnnotations,
> 2422:                                                     ClassFileDumper dumper,
> 2423:                                                     ClassOption ... options) {

Suggestion:

                                                    ClassOption[] options) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/21002#pullrequestreview-2303790450
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759296535
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759296736
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759297371
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759297457
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759297538

From naoto at openjdk.org  Fri Sep 13 18:39:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Sep 2024 18:39:42 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ
 files [v2]
In-Reply-To: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
Message-ID: <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>

> Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
> ...
>       The main source files' time zone abbreviations now use %z,
>       supported by zic since release 2015f and used in vanguard form
>       since release 2022b. For example, America/Sao_Paulo now contains
>       the zone continuation line "-3:00 Brazil %z", which is less error
>       prone than the old "-3:00 Brazil -03/-02". This does not change
>       the represented data: the generated TZif files are unchanged.
>       Rearguard form still avoids %z, to support obsolescent parsers.
> ...
> 
> Also fixed the logic to retrieve the linked tz name that is chaining.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Do not add all links

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20979/files
  - new: https://git.openjdk.org/jdk/pull/20979/files/142a2f3c..204041ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20979&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20979&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20979/head:pull/20979

PR: https://git.openjdk.org/jdk/pull/20979

From jbhateja at openjdk.org  Fri Sep 13 18:40:53 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 18:40:53 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v9]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <gQfX6_8rLhl1mD_Zt2VMzGULcRZRlOSblja6zp-G004=.49836b22-d4f2-4db5-9bde-2ee8b5a8f3c8@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Documentation suggestions from Paul.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/d3ee3104..1c00f417

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=07-08

  Stats: 36 lines in 1 file changed: 23 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From darcy at openjdk.org  Fri Sep 13 18:47:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 18:47:05 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method [v2]
In-Reply-To: <VeVKQLO2yVoDsvdrz3aYqe-JnA7teVnVLMrEOyiAcx4=.ce3c56c9-196c-4e18-a4cd-58039126d597@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
 <VeVKQLO2yVoDsvdrz3aYqe-JnA7teVnVLMrEOyiAcx4=.ce3c56c9-196c-4e18-a4cd-58039126d597@github.com>
Message-ID: <qQZdF94kXTd3bPG-rNOKql8Qf526N36JHIH8MEaybUM=.85336c78-a65b-4b64-82a8-40e08f38ea80@github.com>

On Fri, 13 Sep 2024 08:56:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> `Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Slight improvement.

src/java.base/share/classes/java/lang/Math.java line 3325:

> 3323:         if (scaleFactor > -DoubleConsts.EXP_BIAS) {
> 3324:             if (scaleFactor <= DoubleConsts.EXP_BIAS) {
> 3325:                 return d * longBitsToDouble((long) (scaleFactor + DoubleConsts.EXP_BIAS) << PRECISION - 1);

The longBitsToDouble call is basically an inline form of powerOfTwoD. I'd prefer to see that method used for clearer semantics. Optimization of  powerOfTwoD would be fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20948#discussion_r1759320117

From rgiulietti at openjdk.org  Fri Sep 13 18:59:05 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Sep 2024 18:59:05 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method [v2]
In-Reply-To: <qQZdF94kXTd3bPG-rNOKql8Qf526N36JHIH8MEaybUM=.85336c78-a65b-4b64-82a8-40e08f38ea80@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
 <VeVKQLO2yVoDsvdrz3aYqe-JnA7teVnVLMrEOyiAcx4=.ce3c56c9-196c-4e18-a4cd-58039126d597@github.com>
 <qQZdF94kXTd3bPG-rNOKql8Qf526N36JHIH8MEaybUM=.85336c78-a65b-4b64-82a8-40e08f38ea80@github.com>
Message-ID: <ZZs0oOQPvejOxXt0zhvgW6-eTLMH8yJ1RJB9051H-h0=.7ed2cdd6-1dc4-40a9-a661-32b40011544f@github.com>

On Fri, 13 Sep 2024 18:44:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Slight improvement.
>
> src/java.base/share/classes/java/lang/Math.java line 3325:
> 
>> 3323:         if (scaleFactor > -DoubleConsts.EXP_BIAS) {
>> 3324:             if (scaleFactor <= DoubleConsts.EXP_BIAS) {
>> 3325:                 return d * longBitsToDouble((long) (scaleFactor + DoubleConsts.EXP_BIAS) << PRECISION - 1);
> 
> The longBitsToDouble call is basically an inline form of powerOfTwoD. I'd prefer to see that method used for clearer semantics. Optimization of  powerOfTwoD would be fine.

I considered using `powerOfTwoD` but it uses a `long` `+`, and performs an additional masking which seems useless or over-cautious and does not help if `n` is out of range (assuming the assert is not enabled).

What about a `private` similar method that just does the bare minimum and which could also be invoked by `powerOfTwoD`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20948#discussion_r1759335507

From darcy at openjdk.org  Fri Sep 13 19:04:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 19:04:05 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method [v2]
In-Reply-To: <ZZs0oOQPvejOxXt0zhvgW6-eTLMH8yJ1RJB9051H-h0=.7ed2cdd6-1dc4-40a9-a661-32b40011544f@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
 <VeVKQLO2yVoDsvdrz3aYqe-JnA7teVnVLMrEOyiAcx4=.ce3c56c9-196c-4e18-a4cd-58039126d597@github.com>
 <qQZdF94kXTd3bPG-rNOKql8Qf526N36JHIH8MEaybUM=.85336c78-a65b-4b64-82a8-40e08f38ea80@github.com>
 <ZZs0oOQPvejOxXt0zhvgW6-eTLMH8yJ1RJB9051H-h0=.7ed2cdd6-1dc4-40a9-a661-32b40011544f@github.com>
Message-ID: <YwZ6JZ5TvpDSTLX9hBQ1UmIwgpqOnA7H8ug-yt4qUIo=.8601ba02-82df-42ed-941e-bff4b83dd87e@github.com>

On Fri, 13 Sep 2024 18:56:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> I considered using `powerOfTwoD` but it uses a `long` `+`, and performs an additional masking which seems useless or over-cautious and does not help if `n` is out of range (assuming the assert is not enabled).
> 
> What about a `private` similar method that just does the bare minimum and which could also be invoked by `powerOfTwoD`?

Sure; having a raw "powerOfTwo0" that didn't do any checks, etc. as a kernel operation sounds fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20948#discussion_r1759342756

From jbhateja at openjdk.org  Fri Sep 13 19:09:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 19:09:04 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <aKDb17oHvlaJb87VFKyg4VfrTv99EFC31LQwSdNYA7o=.762420cc-cfc6-45a9-9307-0ce24bb6eff9@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <aqBblQCYrW4fItjHak45eHoINlpw0pkOWuylqGpgAJY=.9bdd44e2-493b-4b04-98c3-7be4e96736ca@github.com>
 <aKDb17oHvlaJb87VFKyg4VfrTv99EFC31LQwSdNYA7o=.762420cc-cfc6-45a9-9307-0ce24bb6eff9@github.com>
Message-ID: <w6IeB-041I0TFj7XuChoL8X6jChHz907PGvLp0oBu40=.d86f3288-124a-4131-96c3-74883a15af74@github.com>

On Fri, 13 Sep 2024 18:24:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 2206:
>> 
>>> 2204:   const Type * byte_bt = Type::get_const_basic_type(T_BYTE);
>>> 2205:   const TypeVect * byte_vt  = TypeVect::make(byte_bt, num_elem);
>>> 2206:   Node* byte_shuffle = gvn().transform(VectorCastNode::make(cast_vopc, v1, T_BYTE, num_elem));
>> 
>> We can be optimal here and prevent down casting and subsequent load shuffles in applicable scenarios, e.g. indexes held in integral vectors.
>
> @jatin-bhateja If you could expand on this comment with specific cases it will be helpful. The loadShuffle generation is needed for platform specific handling of shuffles and cannot be optimized out here.

Hi @sviswa7, I was suggesting emitting toShuffle() + toVector() only if it's needed under a target specific hook, since indexes are anyways passed though vector. Please let me know if you find blow explanation too constraining.
https://github.com/openjdk/jdk/pull/20508#issuecomment-2349801299

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759345567

From sviswanathan at openjdk.org  Fri Sep 13 19:17:04 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Sep 2024 19:17:04 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <w6IeB-041I0TFj7XuChoL8X6jChHz907PGvLp0oBu40=.d86f3288-124a-4131-96c3-74883a15af74@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <aqBblQCYrW4fItjHak45eHoINlpw0pkOWuylqGpgAJY=.9bdd44e2-493b-4b04-98c3-7be4e96736ca@github.com>
 <aKDb17oHvlaJb87VFKyg4VfrTv99EFC31LQwSdNYA7o=.762420cc-cfc6-45a9-9307-0ce24bb6eff9@github.com>
 <w6IeB-041I0TFj7XuChoL8X6jChHz907PGvLp0oBu40=.d86f3288-124a-4131-96c3-74883a15af74@github.com>
Message-ID: <2483R4bBJDN4UpBlRJSQVE2KjdctYIy0j__kzRGRDHc=.71baed04-9185-4111-a3ce-ce32a40cb570@github.com>

On Fri, 13 Sep 2024 19:04:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @jatin-bhateja If you could expand on this comment with specific cases it will be helpful. The loadShuffle generation is needed for platform specific handling of shuffles and cannot be optimized out here.
>
> Hi @sviswa7, I was suggesting emitting toShuffle() + toVector() only if it's needed under a target specific hook, since indexes are anyways passed though vector. Please let me know if you find blow explanation too constraining.
> https://github.com/openjdk/jdk/pull/20508#issuecomment-2349801299

I think VectorLoadShuffle removal optimizations should be a separate PR and well thought out. So far the contract has been that rearrange always gets the shuffle through VectorLoadShuffle and I would like to keep that contract in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759361459

From ihse at openjdk.org  Fri Sep 13 19:33:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 13 Sep 2024 19:33:18 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
Message-ID: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com>

On Thu, 12 Sep 2024 02:10:00 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Clean up to address reviewer comments

make/modules/java.base/lib/CoreLibraries.gmk line 68:

> 66:     JDK_LIBS := libjvm, \
> 67:     LIBS_linux := $(LIBDL) -lpthread, \
> 68:     LIBS_aix := $(LIBDL) $(LIBM),\

Suggestion:

    LIBS_aix := $(LIBDL) $(LIBM), \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759390367

From rgiulietti at openjdk.org  Fri Sep 13 19:33:51 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Sep 2024 19:33:51 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method [v3]
In-Reply-To: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
Message-ID: <Aai36Xvx_vGYURofVEYLGtbdIFFXXxTs_pcDHFarD8M=.d070989f-c43b-4253-8bc5-62786e11eeec@github.com>

> `Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Introduce primPowerOfTwoD and make use of it.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20948/files
  - new: https://git.openjdk.org/jdk/pull/20948/files/2b7c7061..1095824a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20948&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20948&range=01-02

  Stats: 15 lines in 1 file changed: 6 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20948/head:pull/20948

PR: https://git.openjdk.org/jdk/pull/20948

From psandoz at openjdk.org  Fri Sep 13 19:48:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 13 Sep 2024 19:48:04 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <gFiugusEK31pCIqMQgnlNSGQLhykQjPBbUoxzLcGpG8=.a5a333b3-44a5-4657-b9f9-3d7f51d6229a@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <L3raQIsBWTc504BaXOu5vM0JbmlPKywyLzbbb6mD8dg=.88612fb2-b53a-4a1b-9538-daaeaca66d9d@github.com>
 <gFiugusEK31pCIqMQgnlNSGQLhykQjPBbUoxzLcGpG8=.a5a333b3-44a5-4657-b9f9-3d7f51d6229a@github.com>
Message-ID: <GwQIFcz4V6pibMfRxVAqOyUrOmgE9iwkzNItZVaY6j8=.de6221ba-8ef8-4773-a9aa-11b07e9fa456@github.com>

On Fri, 13 Sep 2024 18:17:21 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> 
> The guidance from Paul Sandoz and John Rose is to keep the the partial wrapping at shuffle construction as is for now and only change the rearrange and selectFrom apis.

Yes, we are trying to take smaller incremental steps. Once the we are done with this work we can step back and discuss/review what to do about shuffles.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2350039460

From liach at openjdk.org  Fri Sep 13 19:54:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 19:54:12 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v5]
In-Reply-To: <lV-6mY29s_6WZf-nYH6SyWbshj24wMaTnd9g4TFQtoA=.f93efaea-c3d6-498c-a355-93a6719eb4c0@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <lV-6mY29s_6WZf-nYH6SyWbshj24wMaTnd9g4TFQtoA=.f93efaea-c3d6-498c-a355-93a6719eb4c0@github.com>
Message-ID: <5uhwnZlHf_G128QSItqLuPEFeWWop7ZZb54QwUc51Ao=.8a2bba22-3578-4664-a463-1476410a3692@github.com>

On Fri, 13 Sep 2024 17:14:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_classfile_loadconstant_2020408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>  - Merge remote-tracking branch 'upstream/master' into optim_classfile_loadconstant_2020408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>  - comments
>  - fix comment
>  - since 24
>  - optimize loadConstant

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 628:

> 626: 
> 627:     /**
> 628:      * Generate an instruction pushing a constant int value onto the operand stack.

@wenshao After offline discussion with @kevinb9n, we think we should add another sentence in the API specification:

This is identical to {@link #loadConstant(ConstantDesc) loadConstant(Integer.valueOf(value))}.

And repeat this for long, float, and double versions (with `Long.valueOf(value)` etc.)
This avoids confusions around this API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1759413792

From psandoz at openjdk.org  Fri Sep 13 20:09:05 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 13 Sep 2024 20:09:05 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <LEKZfAvJn-sl-reNOzxAGo9zphcAGSJV53naE7tFG50=.3cca463e-b3ac-4159-a3c2-a4d34a6bc7e2@github.com>

On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2439:

> 2437:                    (v1, s_, m_) -> v1.uOp((i, a) -> {
> 2438:                         int ei = s_.laneSource(i);
> 2439:                         return ei < 0  || !m_.laneIsSet(i) ? 0 : v1.lane(ei);

The `ei < 0` test is redundant.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 2637:

> 2635:      *
> 2636:      * For each lane {@code N} of the shuffle, and for each lane
> 2637:      * source index {@code I=s.wrapIndex(s.laneSource(N))} in the shuffle,

The pseudo code below starting at line 2644 needs adjusting to:

Vector<E> r = this.rearrange(s);
return broadcast(0).blend(r, m);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 2755:

> 2753:      *
> 2754:      * The result is the same as the expression
> 2755:      * {@code v.rearrange(this.toShuffle().wrapIndexes())}.

Since we also adjusted `rearrange` the existing expression is fine, recommend no change here and to the mask accepting version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759431093
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759428672
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759418829

From lancea at openjdk.org  Fri Sep 13 20:18:17 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Sep 2024 20:18:17 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits
Message-ID: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>

Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)

As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.

Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

-------------

Commit messages:
 - Improve ZipOuputSream validation of  MAX CEN Header field limits

Changes: https://git.openjdk.org/jdk/pull/21003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336025
  Stats: 223 lines in 4 files changed: 203 ins; 11 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21003/head:pull/21003

PR: https://git.openjdk.org/jdk/pull/21003

From liach at openjdk.org  Fri Sep 13 20:38:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 20:38:09 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits
In-Reply-To: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
Message-ID: <f4O7ymF1JVmt1v6_VEv1KQ2TthkUyuoWaX7yD2uqZ3M=.d018c3a2-a09f-4918-811f-955953e7b8fb@github.com>

On Fri, 13 Sep 2024 17:40:21 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
> 
> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
> 
> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

src/java.base/share/classes/java/util/zip/ZipEntry.java line 42:

> 40:  * <P>
> 41:  * The combined length of the entry name, the extra field data, the
> 42:  * entry comment and {@link ZipFile#CENHDR CEN Header size}, must not

I think you flipped the usage of `@link` and `@linkplain` in this spec addition. `@link` renders code with hyperlink, and `@linkplain` renders like regular body font with hyperlink.

And the constant is available in this class too, so no need to link to `ZipFile` really.
Suggestion:

 * entry comment and {@linkplain #CENHDR CEN Header size}, must not

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1759452318

From bpb at openjdk.org  Fri Sep 13 20:41:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 20:41:27 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>

> 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 incrementally with one additional commit since the last revision:

  8337143: Minor makefile tweak

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/853d3491..b54b1683

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bpb at openjdk.org  Fri Sep 13 20:41:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 20:41:28 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com>
Message-ID: <8y7e4b_Phw8ehQRM0kbQom0w3WD91u7B5ujYIiGl6P4=.eab2e1ad-3a81-4c7e-8e14-cc6b51a377d0@github.com>

On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Clean up to address reviewer comments
>
> make/modules/java.base/lib/CoreLibraries.gmk line 68:
> 
>> 66:     JDK_LIBS := libjvm, \
>> 67:     LIBS_linux := $(LIBDL) -lpthread, \
>> 68:     LIBS_aix := $(LIBDL) $(LIBM),\
> 
> Suggestion:
> 
>     LIBS_aix := $(LIBDL) $(LIBM), \

So changed in b54b168.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759474420

From psandoz at openjdk.org  Fri Sep 13 21:58:16 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 13 Sep 2024 21:58:16 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v10]
In-Reply-To: <KMPrHf1coga5JNG_Lfz3ync1tWLIFWj6IQ0Qf4r4cfU=.763eebab-9a4b-4a67-bbb1-dcebcff4adb0@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <KMPrHf1coga5JNG_Lfz3ync1tWLIFWj6IQ0Qf4r4cfU=.763eebab-9a4b-4a67-bbb1-dcebcff4adb0@github.com>
Message-ID: <CzTfJZn1K0TzBHRnCEE7hRvBNm5leTXWghsPRGZ8nNo=.a01b8032-3ee4-4e77-a13b-00e3fa7884b0@github.com>

On Fri, 13 Sep 2024 16:20:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Documentation change suggerstion from Paul

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 573:

> 571:      * @see VectorMath#addSaturating(int, int)
> 572:      */
> 573:     public static final Associative SADD = assoc("SADD", "+", VectorSupport.VECTOR_OP_SADD, VO_NOFP+VO_ASSOC);

I don't believe saturation arithmetic is associative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1759556540

From psandoz at openjdk.org  Fri Sep 13 22:02:30 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 13 Sep 2024 22:02:30 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v10]
In-Reply-To: <KMPrHf1coga5JNG_Lfz3ync1tWLIFWj6IQ0Qf4r4cfU=.763eebab-9a4b-4a67-bbb1-dcebcff4adb0@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <KMPrHf1coga5JNG_Lfz3ync1tWLIFWj6IQ0Qf4r4cfU=.763eebab-9a4b-4a67-bbb1-dcebcff4adb0@github.com>
Message-ID: <0PApPK8O06mwyZXwM5XpEGPDdmeqaxhX-llQryWSUpo=.03ae9624-b809-48ca-8e07-242aad3e9df2@github.com>

On Fri, 13 Sep 2024 16:20:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Documentation change suggerstion from Paul

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 589:

> 587:      * @see VectorMath#minUnsigned(int, int) (int, int)
> 588:      */
> 589:     public static final Associative UMIN = assoc("UMIN", "umin", VectorSupport.VECTOR_OP_UMIN, VO_NOFP+VO_ASSOC);

We should rename the existing unsigned compare operators to use the same naming scheme i.e., s/UNSIGNED_LT/ULT etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1759558844

From bpb at openjdk.org  Fri Sep 13 22:05:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 22:05:40 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v6]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Move symbolic link verbiage from class to constructor doc in FIS/FOS/RAF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/584742e8..f492c36a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=04-05

  Stats: 54 lines in 4 files changed: 26 ins; 16 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From bpb at openjdk.org  Fri Sep 13 22:05:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 22:05:41 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v5]
In-Reply-To: <0IeuGaaPy8TJq6fBQ4TTsOvEDXLcdp4zcxqt9k48Q-g=.a4071de3-bcd9-4677-a9c1-2b963fe63cbf@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <VZiSyJeS1tcrvR-0sQUKAhVF9Wu-9eUaZRI2wFJx9ZA=.46bb62f5-2c33-473e-bdb2-b50a2edfc1f7@github.com>
 <udRAyNdwVIw4bcwwrvRGb96qC3wVg9e3rqd4fOPzfNY=.e7d1475c-56af-418e-936e-25326d846ca7@github.com>
 <0IeuGaaPy8TJq6fBQ4TTsOvEDXLcdp4zcxqt9k48Q-g=.a4071de3-bcd9-4677-a9c1-2b963fe63cbf@github.com>
Message-ID: <3hHAZd295v_YxWx7a7gEgm8lg7oCfb7hfH0XOEC5MOQ=.c4e4cefc-1fb5-47f2-9d73-2e3e751fff42@github.com>

On Tue, 10 Sep 2024 18:05:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/File.java line 1440:
>> 
>>> 1438:      * Renames the file denoted by this abstract pathname.  If this pathname
>>> 1439:      * denotes a symbolic link, then the link itself, not its target, will be
>>> 1440:      * renamed.
>> 
>> For FIS/FOS/RAF it's just two constructors in each that follow links so I'm wondering if might be better to put the text there. Also in the case of FOS (and RAF when "w" is in the mode) it will follow the linking when creating (or truncating in the case of FOS) the file and part of wonders if we need to say more on this.
>
>> or truncating in the case of FOS
> 
> For that matter, I don't see where truncation is explicitly mentioned in the FOS doc.

These comments are addressed in f492c36.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1759560148

From redestad at openjdk.org  Fri Sep 13 22:25:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 13 Sep 2024 22:25:13 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v2]
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <XQ2lryWWzj1PLYTEl1IPFhljnGPhGejC35E33v3s-cQ=.eeb1546b-4d17-4c14-8b89-2752d18ce540@github.com>

> Simple internal refactor to load a few classes less on startup. Arguably cleaner.

Claes Redestad has updated the pull request incrementally with six additional commits since the last revision:

 - no clone
 - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21002/files
  - new: https://git.openjdk.org/jdk/pull/21002/files/681ee5ea..bd99e331

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21002/head:pull/21002

PR: https://git.openjdk.org/jdk/pull/21002

From sviswanathan at openjdk.org  Fri Sep 13 22:30:36 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Sep 2024 22:30:36 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v2]
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20634/files
  - new: https://git.openjdk.org/jdk/pull/20634/files/694aceb5..428f2289

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=00-01

  Stats: 14 lines in 8 files changed: 0 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20634.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20634/head:pull/20634

PR: https://git.openjdk.org/jdk/pull/20634

From duke at openjdk.org  Fri Sep 13 22:31:01 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 13 Sep 2024 22:31:01 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v5]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <LhH7ziOiR92Lpku9V4xlBCQROVYzpJqJPo4PF7DcYcQ=.73511b79-0d14-4f8e-885e-5021a82b3301@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  quad precision tanh tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/4aa52bfd..d4ddc313

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=03-04

  Stats: 859 lines in 1 file changed: 859 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From duke at openjdk.org  Fri Sep 13 22:33:12 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 13 Sep 2024 22:33:12 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
 <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
 <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
Message-ID: <0cm-1lCXQVJaCJbfp7evFyNvkLFxwUyfSukdy40aVxY=.7129df0b-d9a0-4a3b-b7f6-53f767b01ef6@github.com>

On Wed, 11 Sep 2024 01:59:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> If the test is going to use randomness, then its jtreg tags should include
>>> 
>>> `@key randomness`
>>> 
>>> and it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.
>> 
>> Please see the test updated to use `@key randomness` and` jdk.test.lib.RandomFactory` to get and Random object.
>> 
>>> The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.
>>> For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).
>>>
>> So far the tests haven't failed with error of 2.5ulp. Would it be better to make it 5ulp? Please let me know.
>
> So far, this will be the only intrinsic implementation of tanh. Therefore, at the moment it is just checking the consistency of the intrinsic implementation with StrictMath/FDLIBM tanh. If the intrinsic has a ~1 ulp accuracy, it would be expected to often be within 2.5 ulps of FDLIBM tanh. However, as written the regression test would not necessarily pass against any allowable Math.tanh implementation, which is the usual criteria for java.lang.Math tests that aren't otherwise constrained (such as by being limited to a given subset of platforms).
> 
> If there was a correctly rounded tanh to compare against, then this style of testing would be valid.
> 
> Are there any plan to intrinsify sinh or cosh?

Hi Joe (@jddarcy),

As suggested by Sandhya (@sviswa7), I added ~750 fixed point tests for tanh in `TanhTests.java` using the quad precision tanh implementation in libquadmath library from gcc. 

Please let me know if this looks good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1759579101

From sviswanathan at openjdk.org  Fri Sep 13 22:33:18 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Sep 2024 22:33:18 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <GwQIFcz4V6pibMfRxVAqOyUrOmgE9iwkzNItZVaY6j8=.de6221ba-8ef8-4773-a9aa-11b07e9fa456@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <L3raQIsBWTc504BaXOu5vM0JbmlPKywyLzbbb6mD8dg=.88612fb2-b53a-4a1b-9538-daaeaca66d9d@github.com>
 <gFiugusEK31pCIqMQgnlNSGQLhykQjPBbUoxzLcGpG8=.a5a333b3-44a5-4657-b9f9-3d7f51d6229a@github.com>
 <GwQIFcz4V6pibMfRxVAqOyUrOmgE9iwkzNItZVaY6j8=.de6221ba-8ef8-4773-a9aa-11b07e9fa456@github.com>
Message-ID: <sE0BCgcjpvciNej6Z7LDyCCo15keb1KPl97E50ixQjY=.41f0b132-ac4f-4559-9cea-8b948b7c3111@github.com>

On Fri, 13 Sep 2024 19:45:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> Given `rearrange` with 1 vector gets wrapping indices semantics. I think we should stop normalizing indices when converting a `Vector` into a `VectorShuffle` (currently we wrap all out-of-bound elements to `[-VLEN, 0)`). Then the rearrange with 2 vectors will also wrap similarly (all indices are `& (VLEN * 2 - 1)`, then indices `[0, VLEN)` maps to the first vector and indices `[VLEN, 2 * VLEN)` map to the second vector). We will normalize the indices when we invoke `VectorShuffle::toVector` which I think is much less used than `Vector::toShuffle`. What do you think?
>> 
>> The guidance from Paul Sandoz and John Rose is to keep the the partial wrapping at shuffle construction as is for now and only change the rearrange and selectFrom apis.
>
>> 
>> The guidance from Paul Sandoz and John Rose is to keep the the partial wrapping at shuffle construction as is for now and only change the rearrange and selectFrom apis.
> 
> Yes, we are trying to take smaller incremental steps. Once the we are done with this work we can step back and discuss/review what to do about shuffles.

@PaulSandoz Thanks a lot for the review. I have addressed your review comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2350535307

From duke at openjdk.org  Fri Sep 13 22:36:45 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 13 Sep 2024 22:36:45 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v6]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <rwkPfk02vzVHscuFseCGUGp14yVFd7ezjUVM80cKFkY=.a38665b3-6cf9-45f2-bae1-400bf462d0a4@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/Math/HyperbolicTests.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/d4ddc313..ca3314c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From sviswanathan at openjdk.org  Fri Sep 13 23:13:20 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Sep 2024 23:13:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <0cm-1lCXQVJaCJbfp7evFyNvkLFxwUyfSukdy40aVxY=.7129df0b-d9a0-4a3b-b7f6-53f767b01ef6@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
 <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
 <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
 <0cm-1lCXQVJaCJbfp7evFyNvkLFxwUyfSukdy40aVxY=.7129df0b-d9a0-4a3b-b7f6-53f767b01ef6@github.com>
Message-ID: <N08c2VRDNCMK2udQU3W5m7In_llDorc3APwMxr-u_CA=.113c4227-2360-4258-b6fc-1ea77922466d@github.com>

On Fri, 13 Sep 2024 22:30:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> So far, this will be the only intrinsic implementation of tanh. Therefore, at the moment it is just checking the consistency of the intrinsic implementation with StrictMath/FDLIBM tanh. If the intrinsic has a ~1 ulp accuracy, it would be expected to often be within 2.5 ulps of FDLIBM tanh. However, as written the regression test would not necessarily pass against any allowable Math.tanh implementation, which is the usual criteria for java.lang.Math tests that aren't otherwise constrained (such as by being limited to a given subset of platforms).
>> 
>> If there was a correctly rounded tanh to compare against, then this style of testing would be valid.
>> 
>> Are there any plan to intrinsify sinh or cosh?
>
> Hi Joe (@jddarcy),
> 
> As suggested by Sandhya (@sviswa7), I added ~750 fixed point tests for tanh in `TanhTests.java` using the quad precision tanh implementation in libquadmath library from gcc. 
> 
> Please let me know if this looks good.

@vamsi-parasa In my thoughts the best way to do this is add the additional tests points to HyperbolicTests.java itself in the testcases array of testTanh() method. We should remove all the other changes from HyperbolicTests.java. Also no need for separate TanhTests.java file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1759602199

From redestad at openjdk.org  Fri Sep 13 23:54:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 13 Sep 2024 23:54:05 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v2]
In-Reply-To: <zPF2aHJ6nsqBockMSKZGrMGRgcq72BIyBB0JnEr_90Y=.47c1fbf7-6228-4a85-b827-ab61d3c62c20@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <zPF2aHJ6nsqBockMSKZGrMGRgcq72BIyBB0JnEr_90Y=.47c1fbf7-6228-4a85-b827-ab61d3c62c20@github.com>
Message-ID: <60MZbpF0QkVyavJcWc9Nltga2URvikHegSJwi5vSXEQ=.5bd5a51a-99fe-4bb7-80c8-11b6f0b9b374@github.com>

On Fri, 13 Sep 2024 15:57:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - no clone
>>  - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2223:
> 
>> 2221:             }
>> 2222: 
>> 2223:             return makeHiddenClassDefiner(bytes.clone(), false, options.clone())
> 
> Why do we need to clone here, but not in `defineHiddenClass`? `makeHiddenClassDefiner` seems to always turn the options in flags right away, so I don't think we need to clone?

I started out adding the .clone() as a standard precaution, analyzed to make sure it wasn't needed then removed it in one out of two places. Now both removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759615920

From redestad at openjdk.org  Sat Sep 14 00:16:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 14 Sep 2024 00:16:40 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v3]
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <V2GRIc2bf0Kat-e9dQ3UlKKGFlYp9oxTk1CrSL64dbs=.d5b28d7d-fa02-4a39-8600-b36e11a338dc@github.com>

> Simple internal refactor to load a few classes less on startup. Arguably cleaner.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add override to fix build error and eliminate all allocations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21002/files
  - new: https://git.openjdk.org/jdk/pull/21002/files/bd99e331..877b1f46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=01-02

  Stats: 21 lines in 3 files changed: 18 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21002/head:pull/21002

PR: https://git.openjdk.org/jdk/pull/21002

From redestad at openjdk.org  Sat Sep 14 01:12:47 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 14 Sep 2024 01:12:47 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v4]
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <iT90UKXYNav6qYDfwt-iZ0yYlCOGkdR3UjSladylYC8=.b4c1eb0b-7412-4402-851b-6ef0ac0384d8@github.com>

> Simple internal refactor to load a few classes less on startup. Arguably cleaner.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21002/files
  - new: https://git.openjdk.org/jdk/pull/21002/files/877b1f46..e2482344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21002/head:pull/21002

PR: https://git.openjdk.org/jdk/pull/21002

From swen at openjdk.org  Sat Sep 14 02:45:47 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 14 Sep 2024 02:45:47 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v6]
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

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/20761/files
  - new: https://git.openjdk.org/jdk/pull/20761/files/9a365337..a1e6e3c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=04-05

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20761/head:pull/20761

PR: https://git.openjdk.org/jdk/pull/20761

From liach at openjdk.org  Sat Sep 14 03:00:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 14 Sep 2024 03:00:05 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v6]
In-Reply-To: <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
Message-ID: <8zLDxl1JoE7s1LG0rZy37yOL8iM1MHQS3_uwGhjWYZI=.0f73efd4-f459-40b2-b9de-13ae134dfeee@github.com>

On Sat, 14 Sep 2024 02:45:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

Thanks for this improvement.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20761#pullrequestreview-2304362032

From alanb at openjdk.org  Sat Sep 14 06:50:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Sep 2024 06:50:07 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v6]
In-Reply-To: <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
Message-ID: <cxr64BoreKGvsqr_5v4bLI1Yj8se3IfNP_uLmjCj4rw=.65d2bcf7-11b3-4269-852a-4eb130b6568e@github.com>

On Fri, 13 Sep 2024 22:05:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Move symbolic link verbiage from class to constructor doc in FIS/FOS/RAF

src/java.base/share/classes/java/io/FileInputStream.java line 90:

> 88:      * in the file system.  {@linkplain java.nio.file##links Symbolic links}
> 89:      * are automatically redirected to the <i>target</i> of the link.
> 90:      * A new {@code FileDescriptor}

In passing (and not for this PR) is that we should probably change the first sentence to say that it opens an existing file and drop the use of "connection".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1759682290

From alanb at openjdk.org  Sat Sep 14 07:06:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Sep 2024 07:06:05 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v6]
In-Reply-To: <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
Message-ID: <9Myxrbgw0SuFOLzWZeAuK9I7lmEN4488gDr3lmyFBtc=.ae149a97-fa20-4152-ab2a-7bbe65f10843@github.com>

On Fri, 13 Sep 2024 22:05:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Move symbolic link verbiage from class to constructor doc in FIS/FOS/RAF

src/java.base/share/classes/java/io/FileOutputStream.java line 103:

> 101:      * are automatically redirected to the <i>target</i> of the link.
> 102:      * If the file or link target exists, then it will be truncated.
> 103:      * A new {@code FileDescriptor} object is

This wording gives the impression that a link can be truncated :-)

I think the second sentence needs to say that it truncates an existing file, otherwise creates a new file. Then follow with the sentence on sym link behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1759684286

From alanb at openjdk.org  Sat Sep 14 07:12:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Sep 2024 07:12:06 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v6]
In-Reply-To: <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
Message-ID: <KX6pS0Fy6qQR9WKDTZUl0z4CpvW4fXe6XfzmG5mR_Ng=.a2ec7fff-9aa1-47b4-9cf2-0d233dbdd160@github.com>

On Fri, 13 Sep 2024 22:05:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Move symbolic link verbiage from class to constructor doc in FIS/FOS/RAF

src/java.base/share/classes/java/io/RandomAccessFile.java line 108:

> 106:      * are automatically redirected to the <i>target</i> of the link.
> 107:      * If the access mode specifies writing and the file or link target exists,
> 108:      * then it will be truncated.

I think you've copied the text from FOS but it doesn't work here as RAF doesn't truncate.

For "r" mode, it opens an existing file. For the "rw" and variants, it opens an existing file, or creates a new file if it doesn't exist.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1759684960

From duke at openjdk.org  Sat Sep 14 07:53:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 14 Sep 2024 07:53:04 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v4]
In-Reply-To: <60MZbpF0QkVyavJcWc9Nltga2URvikHegSJwi5vSXEQ=.5bd5a51a-99fe-4bb7-80c8-11b6f0b9b374@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <zPF2aHJ6nsqBockMSKZGrMGRgcq72BIyBB0JnEr_90Y=.47c1fbf7-6228-4a85-b827-ab61d3c62c20@github.com>
 <60MZbpF0QkVyavJcWc9Nltga2URvikHegSJwi5vSXEQ=.5bd5a51a-99fe-4bb7-80c8-11b6f0b9b374@github.com>
Message-ID: <IEQ57gZH0zEZEsIDvhkP2GxLR_ALuLJNUvI4CrLzO1I=.ba12df43-f30f-41b2-8bcc-26c4942bcd8a@github.com>

On Fri, 13 Sep 2024 23:51:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2223:
>> 
>>> 2221:             }
>>> 2222: 
>>> 2223:             return makeHiddenClassDefiner(bytes.clone(), false, options.clone())
>> 
>> Why do we need to clone here, but not in `defineHiddenClass`? `makeHiddenClassDefiner` seems to always turn the options in flags right away, so I don't think we need to clone?
>
> I started out adding the .clone() as a standard precaution, analyzed to make sure it wasn't needed then removed it in one out of two places. Now both removed.

The?public?methods used?to?throw `IllegalArgumentException` when?duplicate class?options were?passed?though, as?a?result of?using?[`Set.of(?)`].

[`Set.of(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Set.html#of(E...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759690770

From jbhateja at openjdk.org  Sat Sep 14 08:30:48 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 14 Sep 2024 08:30:48 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v11]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <nsGvG4R-98mmjpwdO94xfWSnuIEbcTh7HCDYNcE6tfs=.fadb92da-fce8-4a06-a341-310e05fb8a09@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions incorporated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/4301c817..71114d0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=09-10

  Stats: 330 lines in 22 files changed: 0 ins; 0 del; 330 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Sat Sep 14 08:40:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 14 Sep 2024 08:40:44 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v12]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <jJtmOxc9xlDm-_nyovuF4xXeW2KAkvYcqIpC3vyx--g=.cf792925-86f5-49ff-9a22-0b5ad4d0b8d9@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Update AARCH64 specific test using UNSIGNED_* comparison operators.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/71114d0d..ec7c7553

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=10-11

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Sat Sep 14 09:11:06 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 14 Sep 2024 09:11:06 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v2]
In-Reply-To: <2483R4bBJDN4UpBlRJSQVE2KjdctYIy0j__kzRGRDHc=.71baed04-9185-4111-a3ce-ce32a40cb570@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <aqBblQCYrW4fItjHak45eHoINlpw0pkOWuylqGpgAJY=.9bdd44e2-493b-4b04-98c3-7be4e96736ca@github.com>
 <aKDb17oHvlaJb87VFKyg4VfrTv99EFC31LQwSdNYA7o=.762420cc-cfc6-45a9-9307-0ce24bb6eff9@github.com>
 <w6IeB-041I0TFj7XuChoL8X6jChHz907PGvLp0oBu40=.d86f3288-124a-4131-96c3-74883a15af74@github.com>
 <2483R4bBJDN4UpBlRJSQVE2KjdctYIy0j__kzRGRDHc=.71baed04-9185-4111-a3ce-ce32a40cb570@github.com>
Message-ID: <JTiJQyrXzQnqjPmKGTNtn4HsvUdXXAIITXzGYS-VJqI=.14ee21fd-5123-4e0a-b327-1436dec8b704@github.com>

On Fri, 13 Sep 2024 19:14:29 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Hi @sviswa7, I was suggesting emitting toShuffle() + toVector() only if it's needed under a target specific hook, since indexes are anyways passed though vector. Please let me know if you find blow explanation too constraining.
>> https://github.com/openjdk/jdk/pull/20508#issuecomment-2349801299
>
> I think VectorLoadShuffle removal optimizations should be a separate PR and well thought out. So far the contract has been that rearrange always gets the shuffle through VectorLoadShuffle and I would like to keep that contract in this PR.

Hi @sviswa7, @PaulSandoz , I will modify PR#20508 accordingly to honor the contract at IR level and address VectorLoadShuffle optimization for both flavors of selectFrom API in a follow up PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1759701508

From jlu at openjdk.org  Sat Sep 14 09:24:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 14 Sep 2024 09:24:09 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ
 files [v2]
In-Reply-To: <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
 <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
Message-ID: <1-KRYUYxuzPryIf5slU0YGMUzlA3D0x_z2t29RT-pxw=.040937e1-4a6d-4d89-9616-cbca7e2a2f62@github.com>

On Fri, 13 Sep 2024 18:39:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
>> ...
>>       The main source files' time zone abbreviations now use %z,
>>       supported by zic since release 2015f and used in vanguard form
>>       since release 2022b. For example, America/Sao_Paulo now contains
>>       the zone continuation line "-3:00 Brazil %z", which is less error
>>       prone than the old "-3:00 Brazil -03/-02". This does not change
>>       the represented data: the generated TZif files are unchanged.
>>       Rearguard form still avoids %z, to support obsolescent parsers.
>> ...
>> 
>> Also fixed the logic to retrieve the linked tz name that is chaining.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not add all links

IIUC we treat the %z _FORMAT_ the same as the numeric offset _FORMAT_, that is we rely on the _STDOFF_ to calculate the GMT format during runtime.
The changes in `convertGMTName(String f)` seem to accomplish that.

src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 270:

> 268:         ResourceBundle fd = lr.getJavaTimeFormatData();
> 269:         var zi = ZoneInfoFile.getZoneInfo(id);
> 270:         if (zi == null) {

This is an added fallback, and is not related to the "%z" logic right?

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20979#pullrequestreview-2304414315
PR Review Comment: https://git.openjdk.org/jdk/pull/20979#discussion_r1759703352

From jpai at openjdk.org  Sat Sep 14 12:08:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 14 Sep 2024 12:08:36 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v2]
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <1x9DIUcaj87zHB5fUiX-E3RegYsQeObawIqMzTe9xlk=.9c14f1a0-e26f-4e6c-a340-2ed2a69aad9b@github.com>

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove -Xfuture from java man page

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20945/files
  - new: https://git.openjdk.org/jdk/pull/20945/files/6724e579..b1f7f5f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From jpai at openjdk.org  Sat Sep 14 13:14:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 14 Sep 2024 13:14:35 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v3]
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  David's review - move -Xfuture to "Removed Java options"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20945/files
  - new: https://git.openjdk.org/jdk/pull/20945/files/b1f7f5f6..61f2c8f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=01-02

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From duke at openjdk.org  Sat Sep 14 16:11:04 2024
From: duke at openjdk.org (Bernd)
Date: Sat, 14 Sep 2024 16:11:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v3]
In-Reply-To: <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
Message-ID: <XsEeHmr_Jahj6ljbBVVjAH57y7f8RAOCtA3QvPT9PeM=.606277b2-c0ca-433d-8eaa-e546f2edc8c3@github.com>

On Sat, 14 Sep 2024 13:14:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's review - move -Xfuture to "Removed Java options"

What about `-Xdebug` it?s deprecated for remove. It?s not yet moved to the obsolete section of the manual. And we could also remove it from the -X command line help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20945#issuecomment-2351046081

From duke at openjdk.org  Sat Sep 14 16:14:03 2024
From: duke at openjdk.org (Bernd)
Date: Sat, 14 Sep 2024 16:14:03 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v3]
In-Reply-To: <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
Message-ID: <e9kKqNBm-iEgqZxw3nkmJm4unz-JNn23lomjbFzZVDw=.5798aa68-d2fa-4929-aca1-3f3b21d46cdb@github.com>

On Sat, 14 Sep 2024 13:14:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's review - move -Xfuture to "Removed Java options"

src/java.base/share/man/java.1 line 3918:

> 3916: option \f[V]-XX:-ScavengeBeforeFullGC\f[R].
> 3917: .TP
> 3918: \f[V]-Xfuture\f[R]

Maybe also remove the -X help (or at least change its description) in https://github.com/openjdk/jdk/blob/c91fa278fe17ab204beef0fcef1ada6dd0bc37bb/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L144

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1759759938

From duke at openjdk.org  Sat Sep 14 16:18:04 2024
From: duke at openjdk.org (Bernd)
Date: Sat, 14 Sep 2024 16:18:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v3]
In-Reply-To: <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
Message-ID: <eYr9XYCVypu7Qh6ejt8SsIYly2P-Bk2IaytKTXSZB2A=.c8f79387-6223-4ea8-be25-8f20a17caafa@github.com>

On Sat, 14 Sep 2024 13:14:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's review - move -Xfuture to "Removed Java options"

BTW somewhat related, I always wondered if `-Xdiag` is still needed or can be better documented. For example it does not describe that it mainly modified the launcher diagnostic messages (and very little of them)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20945#issuecomment-2351048334

From liach at openjdk.org  Sat Sep 14 20:38:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 14 Sep 2024 20:38:04 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v4]
In-Reply-To: <IEQ57gZH0zEZEsIDvhkP2GxLR_ALuLJNUvI4CrLzO1I=.ba12df43-f30f-41b2-8bcc-26c4942bcd8a@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <zPF2aHJ6nsqBockMSKZGrMGRgcq72BIyBB0JnEr_90Y=.47c1fbf7-6228-4a85-b827-ab61d3c62c20@github.com>
 <60MZbpF0QkVyavJcWc9Nltga2URvikHegSJwi5vSXEQ=.5bd5a51a-99fe-4bb7-80c8-11b6f0b9b374@github.com>
 <IEQ57gZH0zEZEsIDvhkP2GxLR_ALuLJNUvI4CrLzO1I=.ba12df43-f30f-41b2-8bcc-26c4942bcd8a@github.com>
Message-ID: <hic3CxLRlwTsAUh4vAP_hs9udmbbMRNqM2FyhxtgY_E=.89c8893c-914b-4c99-a08f-4989d573ddd9@github.com>

On Sat, 14 Sep 2024 07:50:22 GMT, ExE Boss <duke at openjdk.org> wrote:

>> I started out adding the .clone() as a standard precaution, analyzed to make sure it wasn't needed then removed it in one out of two places. Now both removed.
>
> The?public?methods used?to?throw `IllegalArgumentException` when?duplicate class?options were?passed?though, as?a?result of?using?[`Set.of(?)`].
> 
> [`Set.of(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Set.html#of(E...)

Good note, we might check the option bit is unset before bitwise-or the option bit, or remove this check (this behavior is not specified by this API and might not be relied on)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759808331

From dholmes at openjdk.org  Sat Sep 14 20:55:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 14 Sep 2024 20:55:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v3]
In-Reply-To: <XsEeHmr_Jahj6ljbBVVjAH57y7f8RAOCtA3QvPT9PeM=.606277b2-c0ca-433d-8eaa-e546f2edc8c3@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
 <XsEeHmr_Jahj6ljbBVVjAH57y7f8RAOCtA3QvPT9PeM=.606277b2-c0ca-433d-8eaa-e546f2edc8c3@github.com>
Message-ID: <E0jiKiIZ7QbdSTq9QU6ez4Ore2j_slSE3RWbOnI15KY=.3b36645e-a542-48d9-a5d6-76f275379252@github.com>

On Sat, 14 Sep 2024 16:08:00 GMT, Bernd <duke at openjdk.org> wrote:

> What about `-Xdebug` it?s deprecated for remove. It?s not yet moved to the obsolete section of the manual. And we could also remove it from the -X command line help.

If it is deprecated then it goes in the Deprecated section. The obsoleted section doesn't apply to -X flags but is part of the three-stage removal for Hotspot -XX flags.

> src/java.base/share/man/java.1 line 3918:
> 
>> 3916: option \f[V]-XX:-ScavengeBeforeFullGC\f[R].
>> 3917: .TP
>> 3918: \f[V]-Xfuture\f[R]
> 
> Maybe also remove the -X help (or at least change its description) in https://github.com/openjdk/jdk/blob/c91fa278fe17ab204beef0fcef1ada6dd0bc37bb/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L144

Yes this needs to be removed from the help text.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20945#issuecomment-2351149012
PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1759814814

From liach at openjdk.org  Sun Sep 15 03:05:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 15 Sep 2024 03:05:12 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v4]
In-Reply-To: <iT90UKXYNav6qYDfwt-iZ0yYlCOGkdR3UjSladylYC8=.b4c1eb0b-7412-4402-851b-6ef0ac0384d8@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <iT90UKXYNav6qYDfwt-iZ0yYlCOGkdR3UjSladylYC8=.b4c1eb0b-7412-4402-851b-6ef0ac0384d8@github.com>
Message-ID: <6rdoJTd-W_uzDr4pDJVVFokbYFcfQzc-KJAGOaCs1-0=.49cddfc4-0ce3-4192-928f-b6e94b0456a1@github.com>

On Sat, 14 Sep 2024 01:12:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unused import

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 1912:

> 1910:                 int flags = 0;
> 1911:                 for (ClassOption cp : options) {
> 1912:                     flags |= cp.flag;

If we decide to throw IAE for duplicate flags, then we might have something like:

if ((flags & cp.flag) != 0)
    throw new IllegalArgumentException(); // Maybe a custom message

before this line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1759954092

From epeter at openjdk.org  Sun Sep 15 07:19:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Sun, 15 Sep 2024 07:19:15 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v8]
In-Reply-To: <ZZ2O3vCMVfqBhHvt19K-yy37ekoBDc5NskzH1snNPpY=.11db448d-8342-4f33-9976-da7976085e95@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <yQY-Q1-MIRyJmsvqMsSNXabjOX2pDMnZwIAOCd4VFK8=.a0634119-4f6f-4e54-88d0-0a6859167537@github.com>
 <sEBLsCrcvAsikebe_6UB9Hh3G73tCtyeoyi6BXMIcQc=.66803327-4010-4ab2-8d18-cf2802f8f606@github.com>
 <ZZ2O3vCMVfqBhHvt19K-yy37ekoBDc5NskzH1snNPpY=.11db448d-8342-4f33-9976-da7976085e95@github.com>
Message-ID: <jqt2POOMdku8q0qQhNdb8XD9Pj7mbBGDsCRz0ua9-y8=.af09d668-4e1f-4113-9ac4-95c2c517beba@github.com>

On Fri, 13 Sep 2024 18:27:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Can you please **define** somewhere what it means to `prune indexes`? It does not help me much more than the previous "massaging indexes" you had before I asked you to change it.
> > > Also: I'm a little worried about the semantics change of the RearrangeNode that you did with the changes in RearrangeNode::Ideal. It looks a little "hacky", especially in conjunction with the vector_indexes_needs_massaging method. Can you give a clear definition of the semantics of RearrangeNode and vector_indexes_needs_massaging, please?
> > 
> > 
> > You have also not responded to this yet. It seems to me that before your proposed change, `RearrangeNode` had a clear and easy semantic, and now you somehow "hack it" to work with your `vector_indexes_needs_pruning`. Can you explain please why this makes sense and add a comment to `RearrangeNode` what its semantics is?
> 
> In case target does not directly support two vector selection instruction we lower the IR to its constituents, this is better than intrinsification failure as it saves costly vector boxing penalties.
> 
> Consider in terms of desired compiler IR and not rearrange API semantics, VectorRearrange IR node generally expects shape conformance b/w vector to be permuted and index vector, since shuffle indices are held in byte array based backing storage hence compiler injects VectorLoadShuffle nodes to upcast the byte vector lanes holding indexes to match the input vector lane. Since selectFrom API already passes the indexes through vector hence we can save emitting redundant toShuffle() + toVector() operations in some cases apart from some target specific scenarios e.g. AVX2 targets [do not support direct short vector permute]instruction "VPERMW", hence we need to [massage the index vector](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L8771) to emulate desired permutation using byte permute instruction.
> 
> VectorLoadShuffle abstraction hides target specific index massaging which is why adding a target specific hook like Matcher::vector_indexes_needs_pruning compiler to selectively emit VectorLoadShuffle.

I still do not see a **definition of the semantics of RearrangeNode**:  what inputs does it accept and what does it do with them?

Can you put this explanation as comment in the code, please?

It sounds like this is what the `massaging` / `pruning` is: `emulate desired permutation using byte permute instruction.` You should find an accordingly more suiting name for the method name. Maybe it is something like `must_emulate_permutation_with...`. Or maybe it is rather a `supported` kind of question? I leave that up to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2351426263

From redestad at openjdk.org  Sun Sep 15 12:59:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 15 Sep 2024 12:59:21 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>

> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Improve edge invariant checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21002/files
  - new: https://git.openjdk.org/jdk/pull/21002/files/e2482344..62a88c03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=03-04

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21002/head:pull/21002

PR: https://git.openjdk.org/jdk/pull/21002

From redestad at openjdk.org  Sun Sep 15 12:59:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 15 Sep 2024 12:59:21 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <hic3CxLRlwTsAUh4vAP_hs9udmbbMRNqM2FyhxtgY_E=.89c8893c-914b-4c99-a08f-4989d573ddd9@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <zPF2aHJ6nsqBockMSKZGrMGRgcq72BIyBB0JnEr_90Y=.47c1fbf7-6228-4a85-b827-ab61d3c62c20@github.com>
 <60MZbpF0QkVyavJcWc9Nltga2URvikHegSJwi5vSXEQ=.5bd5a51a-99fe-4bb7-80c8-11b6f0b9b374@github.com>
 <IEQ57gZH0zEZEsIDvhkP2GxLR_ALuLJNUvI4CrLzO1I=.ba12df43-f30f-41b2-8bcc-26c4942bcd8a@github.com>
 <hic3CxLRlwTsAUh4vAP_hs9udmbbMRNqM2FyhxtgY_E=.89c8893c-914b-4c99-a08f-4989d573ddd9@github.com>
Message-ID: <-HtH659GTVQF61x6LVWRtoCGA-B13RKNi65oLHsM8zo=.3f3d0ad9-252c-4e29-ae69-524a5156cc25@github.com>

On Sat, 14 Sep 2024 20:35:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The?public?methods used?to?throw `IllegalArgumentException` when?duplicate class?options were?passed?though, as?a?result of?using?[`Set.of(?)`].
>> 
>> [`Set.of(?)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Set.html#of(E...)
>
> Good note, we might check the option bit is unset before bitwise-or the option bit, or remove this check (this behavior is not specified by this API and might not be relied on)

While the public API specifies IAE to be thrown but not for the case of providing duplicate class options, it would still be behavior change that would require a CSR. And fail-fast is good. I'll add a `Set.of(options)` in the public methods to effect the invariants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1760041593

From lancea at openjdk.org  Sun Sep 15 13:08:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 15 Sep 2024 13:08:06 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits
In-Reply-To: <f4O7ymF1JVmt1v6_VEv1KQ2TthkUyuoWaX7yD2uqZ3M=.d018c3a2-a09f-4918-811f-955953e7b8fb@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <f4O7ymF1JVmt1v6_VEv1KQ2TthkUyuoWaX7yD2uqZ3M=.d018c3a2-a09f-4918-811f-955953e7b8fb@github.com>
Message-ID: <wK535N7T2t4ggJrHFblU_N2VBm_wt4BHr6yN1G0mEyw=.0f85a287-e1a6-4725-9304-f6020950410d@github.com>

On Fri, 13 Sep 2024 20:20:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 42:
> 
>> 40:  * <P>
>> 41:  * The combined length of the entry name, the extra field data, the
>> 42:  * entry comment and {@link ZipFile#CENHDR CEN Header size}, must not
> 
> I think you flipped the usage of `@link` and `@linkplain` in this spec addition. `@link` renders code with hyperlink, and `@linkplain` renders like regular body font with hyperlink.
> 
> And the constant is available in this class too, so no need to link to `ZipFile` really.
> Suggestion:
> 
>  * entry comment and {@linkplain #CENHDR CEN Header size}, must not

Good suggestion.  Updated, per your suggestion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1760043734

From lancea at openjdk.org  Sun Sep 15 13:11:26 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 15 Sep 2024 13:11:26 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
Message-ID: <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>

> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
> 
> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
> 
> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Update @link ->@linkplain

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21003/files
  - new: https://git.openjdk.org/jdk/pull/21003/files/f6746da7..04c723d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21003/head:pull/21003

PR: https://git.openjdk.org/jdk/pull/21003

From liach at openjdk.org  Sun Sep 15 13:19:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 15 Sep 2024 13:19:04 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
Message-ID: <76clIbP2lXhXAZqw_SOkqjPQfASl-mjQ51qx3MDDAO0=.e06ca549-39b8-418f-8c2b-7a150641858c@github.com>

On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve edge invariant checks

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21002#pullrequestreview-2305359678

From duke at openjdk.org  Sun Sep 15 19:19:07 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 15 Sep 2024 19:19:07 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
Message-ID: <nK8cVCwSSRlVWs7LVsX7tzU3a5OmylBxaWHxybCKjBo=.fcfa8c6f-132b-42c5-a281-38fe253dbdcf@github.com>

On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve edge invariant checks

Commit 62a88c0368512e993df09c14d1b98b28b20e3280 introduced a?TOCTOU?issue caused?by double?reading of?a?user?supplied?array, the?fix is?to?convert the?resulting?Set back?to?an?array, or?to?eagerly?convert the?options to?a?flags `int`?while?checking for?duplicates.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2140:

> 2138:             }
> 2139: 
> 2140:             return makeHiddenClassDefiner(bytes.clone(), false, options).defineClassAsLookup(initialize);

Suggestion:

            // Disallow null and duplicate options
            var opts = Set.of(options);

            ensureDefineClassPermission();
            if (!hasFullPrivilegeAccess()) {
                throw new IllegalAccessException(this + " does not have full privilege access");
            }

            return makeHiddenClassDefiner(bytes.clone(), false, opts.toArray(ClassOption.NO_OPTIONS))
                       .defineClassAsLookup(initialize);

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2230:

> 2228: 
> 2229:             return makeHiddenClassDefiner(bytes.clone(), false, options)
> 2230:                        .defineClassAsLookup(initialize, classData);

Suggestion:

            // Disallow null and duplicate options
            var opts = Set.of(options);

            ensureDefineClassPermission();
            if (!hasFullPrivilegeAccess()) {
                throw new IllegalAccessException(this + " does not have full privilege access");
            }

            return makeHiddenClassDefiner(bytes.clone(), false, opts.toArray(ClassOption.NO_OPTIONS))
                       .defineClassAsLookup(initialize, classData);

-------------

PR Review: https://git.openjdk.org/jdk/pull/21002#pullrequestreview-2305560599
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1760276387
PR Review Comment: https://git.openjdk.org/jdk/pull/21002#discussion_r1760276870

From redestad at openjdk.org  Sun Sep 15 20:45:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 15 Sep 2024 20:45:06 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
Message-ID: <zw4alMrwGkxaAXB98QBF-YAL2tLgcjMlFN05PijAXAs=.450040af-6260-4013-907a-abc01b237a48@github.com>

On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve edge invariant checks

> Commit [62a88c0](https://github.com/openjdk/jdk/commit/62a88c0368512e993df09c14d1b98b28b20e3280) introduced a?TOCTOU?issue caused?by double?reading of?a?user?supplied?array

1. Switching to a null value will trigger a NPE when evaluating the option. 
2. Switching values after validation just changes the options from one legal result to another. Weird, but benign. 

I don't think this requires a fix, but putting in a `options = Set.of(options).toArray(NO_OPTIONS);` wouldn't be too bad.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21002#issuecomment-2351785168

From liach at openjdk.org  Sun Sep 15 22:26:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 15 Sep 2024 22:26:07 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
Message-ID: <G9sbb0_O8Kf2-sjMy3uJgkRMEa4NFZXimDTqaittpEo=.d3772a1f-7fd4-4998-809d-57c927190709@github.com>

On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve edge invariant checks

If we leave this toctou, the main concern is racy duplicated elements. Then we should prefer to drop this duplication check at all, or do like my suggestion by checking in the bits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21002#issuecomment-2351812806

From dholmes at openjdk.org  Mon Sep 16 01:24:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Sep 2024 01:24:16 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>

On Fri, 13 Sep 2024 12:29:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Good to see a clean up here but I'm still puzzled by some aspects. And it is a bit hard to track all the changes especially in relation to splashscreen.

Thanks

src/java.base/macosx/native/libjli/java_md_macosx.m line 83:

> 81:  *    point of creating a new thread in CreateExecutionEnvironment, the CreateExecutionEnvironment will check for
> 82:  *    the state flag to see if a new thread has already been spawned and upon noticing that it has, it will skip
> 83:  *    spawning any more threads and will return back from CreateExecutionEnvironment.

My understanding was that this recursive invocation was only needed when switching modes/models. I don't see why it would be needed now.

src/java.base/share/native/libjli/java.c line 38:

> 36:  * One job of the launcher is to remove command line options which the
> 37:  * vm does not understand and will not process. These options include
> 38:  * options which select which style of vm is run (e.g. -client and

Aren't these the only options now?

src/java.base/share/native/libjli/java.c line 1345:

> 1343:             if (JLI_StrCCmp(arg, "-Djava.class.path=") == 0) {
> 1344:                 _have_classpath = JNI_TRUE;
> 1345:             } else if (JLI_StrCmp(arg, "-Djava.awt.headless=true") == 0) {

Was this processing moved from somewhere else?

src/java.base/share/native/libjli/java.c line 1347:

> 1345:             } else if (JLI_StrCmp(arg, "-Djava.awt.headless=true") == 0) {
> 1346:                 /*
> 1347:                  * Checking for headless toolkit option in the some way as AWT does:

Suggestion:

                 * Checking for headless toolkit option in the same way as AWT does:

src/java.base/share/native/libjli/java.c line 1409:

> 1407:         }
> 1408:         // not in headless mode. we now set a couple of env variables that
> 1409:         // will be used later by ShowSplashScreen()

Suggestion:

        // Not in headless mode. We now set a couple of env variables that
        // will be used later by ShowSplashScreen().

src/java.base/share/native/libjli/java.c line 1421:

> 1419: ) {
> 1420: 
> 1421:     // command line specified "-splash:" takes priority over manifest one.

General comment on comment style. Comments should either be written like sentences and start with a Capital and end with a period; or have neither.

src/java.base/unix/native/libjli/java_md.c line 60:

> 58:  *  - JLI_Launch function, which is the entry point to the launcher, calls CreateExecutionEnvironment
> 59:  *
> 60:  *  - CreateExecutionEnvironment does the following (not necessarily in that order):

Suggestion:

 *  - CreateExecutionEnvironment does the following (not necessarily in this order):

-------------

PR Review: https://git.openjdk.org/jdk/pull/20997#pullrequestreview-2305661381
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760429832
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760430531
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760432600
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760431555
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760433596
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760434219
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760434658

From jpai at openjdk.org  Mon Sep 16 01:34:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 01:34:03 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow
In-Reply-To: <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
Message-ID: <1GRsnUvQ7inqOu5CL2h7toc49drPmMAAtuFIUXJzgQA=.16a245d6-e686-4241-800c-43240b94205b@github.com>

On Mon, 16 Sep 2024 01:21:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> And it is a bit hard to track all the changes especially in relation to splashscreen.

If it helps, the webrev instead of the github UI might be better to review this change. Unless of course you were already using that one.

> src/java.base/share/native/libjli/java.c line 1345:
> 
>> 1343:             if (JLI_StrCCmp(arg, "-Djava.class.path=") == 0) {
>> 1344:                 _have_classpath = JNI_TRUE;
>> 1345:             } else if (JLI_StrCmp(arg, "-Djava.awt.headless=true") == 0) {
> 
> Was this processing moved from somewhere else?

Hello David, this was in the SelectVersion() method that we removed in this PR https://github.com/openjdk/jdk/pull/20997/files#diff-c3caaf3e347b1a477e2b7278cb6a35da04a597de5632c13351a6e4e5a2924d21L1154

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20997#issuecomment-2351893609
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760439200

From jpai at openjdk.org  Mon Sep 16 01:38:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 01:38:48 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v2]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <bYxw-Kcg7sV77K2bTmiDkU5uhSp57h-pRzGMeTk0eLg=.c2d1c57d-d7b5-46ca-87ad-d63f56bd0a37@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/311b2e3d..0db4faf3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From dholmes at openjdk.org  Mon Sep 16 01:50:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Sep 2024 01:50:08 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v2]
In-Reply-To: <1GRsnUvQ7inqOu5CL2h7toc49drPmMAAtuFIUXJzgQA=.16a245d6-e686-4241-800c-43240b94205b@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
 <1GRsnUvQ7inqOu5CL2h7toc49drPmMAAtuFIUXJzgQA=.16a245d6-e686-4241-800c-43240b94205b@github.com>
Message-ID: <vbd_zyEAnRb5QzXW0-Wo0yCx47hcQPWMxvBcwk0nu2A=.0e2e0273-e705-48e5-953d-0bb3e63bd0f9@github.com>

On Mon, 16 Sep 2024 01:29:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1345:
>> 
>>> 1343:             if (JLI_StrCCmp(arg, "-Djava.class.path=") == 0) {
>>> 1344:                 _have_classpath = JNI_TRUE;
>>> 1345:             } else if (JLI_StrCmp(arg, "-Djava.awt.headless=true") == 0) {
>> 
>> Was this processing moved from somewhere else?
>
> Hello David, this was in the SelectVersion() method that we removed in this PR https://github.com/openjdk/jdk/pull/20997/files#diff-c3caaf3e347b1a477e2b7278cb6a35da04a597de5632c13351a6e4e5a2924d21L1154

Okay I initially assumed I knew what `SelectVersion` did, now it seems it did half a dozen things and we are still doing a large portion of them, but now moved to other locations in the code: splashscreen, headless ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760446054

From jbhateja at openjdk.org  Mon Sep 16 02:58:41 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Sep 2024 02:58:41 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/1c00f417..7c80bfce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=08-09

  Stats: 321 lines in 51 files changed: 57 ins; 97 del; 167 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Mon Sep 16 03:02:08 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Sep 2024 03:02:08 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v8]
In-Reply-To: <jqt2POOMdku8q0qQhNdb8XD9Pj7mbBGDsCRz0ua9-y8=.af09d668-4e1f-4113-9ac4-95c2c517beba@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <yQY-Q1-MIRyJmsvqMsSNXabjOX2pDMnZwIAOCd4VFK8=.a0634119-4f6f-4e54-88d0-0a6859167537@github.com>
 <sEBLsCrcvAsikebe_6UB9Hh3G73tCtyeoyi6BXMIcQc=.66803327-4010-4ab2-8d18-cf2802f8f606@github.com>
 <ZZ2O3vCMVfqBhHvt19K-yy37ekoBDc5NskzH1snNPpY=.11db448d-8342-4f33-9976-da7976085e95@github.com>
 <jqt2POOMdku8q0qQhNdb8XD9Pj7mbBGDsCRz0ua9-y8=.af09d668-4e1f-4113-9ac4-95c2c517beba@github.com>
Message-ID: <4IqtmftuGBNSj8_1HsI3x9eKBSf4QhpoKELYs1EanLE=.15ae8f1b-f586-403a-88d6-9193bba90fb2@github.com>

On Sun, 15 Sep 2024 07:16:17 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > > Can you please **define** somewhere what it means to `prune indexes`? It does not help me much more than the previous "massaging indexes" you had before I asked you to change it.
> > > > Also: I'm a little worried about the semantics change of the RearrangeNode that you did with the changes in RearrangeNode::Ideal. It looks a little "hacky", especially in conjunction with the vector_indexes_needs_massaging method. Can you give a clear definition of the semantics of RearrangeNode and vector_indexes_needs_massaging, please?
> > > 
> > > 
> > > You have also not responded to this yet. It seems to me that before your proposed change, `RearrangeNode` had a clear and easy semantic, and now you somehow "hack it" to work with your `vector_indexes_needs_pruning`. Can you explain please why this makes sense and add a comment to `RearrangeNode` what its semantics is?
> > 
> > 
> > In case target does not directly support two vector selection instruction we lower the IR to its constituents, this is better than intrinsification failure as it saves costly vector boxing penalties.
> > Consider in terms of desired compiler IR and not rearrange API semantics, VectorRearrange IR node generally expects shape conformance b/w vector to be permuted and index vector, since shuffle indices are held in byte array based backing storage hence compiler injects VectorLoadShuffle nodes to upcast the byte vector lanes holding indexes to match the input vector lane. Since selectFrom API already passes the indexes through vector hence we can save emitting redundant toShuffle() + toVector() operations in some cases apart from some target specific scenarios e.g. AVX2 targets [do not support direct short vector permute]instruction "VPERMW", hence we need to [massage the index vector](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L8771) to emulate desired permutation using byte permute instruction.
> > VectorLoadShuffle abstraction hides target specific index massaging which is why adding a target specific hook like Matcher::vector_indexes_needs_pruning compiler to selectively emit VectorLoadShuffle.
> 
> I still do not see a **definition of the semantics of RearrangeNode**: what inputs does it accept and what does it do with them?
> 
> Can you put this explanation as comment in the code, please?
> 
> It sounds like this is what the `massaging` / `pruning` is: `emulate desired permutation using byte permute instruction.` You should find an accordingly more suiting name for the method name. Maybe it is something like `must_emulate_permutation_with...`. Or maybe it is rather a `supported` kind of question? I leave that up to you.

Hi @eme64 , As per discussion on [PR# 20634 ](https://github.com/openjdk/jdk/pull/20634#discussion_r1759701508), we plan to suppress VectorLoadShuffle bypassing optimization for now and address this as a follow up optimization for both the flavors of selectFrom API.
I have addressed your comments. Kindly verify.

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2351944720

From liach at openjdk.org  Mon Sep 16 03:12:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 03:12:11 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v3]
In-Reply-To: <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
Message-ID: <IqufXD5o7kSyNEawKJNZsojXpD8ENdH3gfrWd1bl6Ws=.7f692601-eb08-4715-9d97-9196bc8f2ef5@github.com>

On Fri, 26 Apr 2024 22:27:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Add test to ensure reproducible iteration order
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Copyright year, revert changes for non-few element collections
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/a920af23...70583024

keep alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2351951180

From jpai at openjdk.org  Mon Sep 16 03:46:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 03:46:28 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v4]
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <2DGe0SzjHQWfkaJS-1UawJTA5gZ0ZyRSPre0fSL2Wjk=.632779c0-869a-4a35-9fe9-6a81251462dd@github.com>

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove Xfuture from launcher usage text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20945/files
  - new: https://git.openjdk.org/jdk/pull/20945/files/61f2c8f5..6e429eef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From jpai at openjdk.org  Mon Sep 16 03:56:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 03:56:39 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v5]
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <-yb7cj89kQoBhTN1Y7y4FaqbiIVIrhRr47r4_485w5s=.9fb11ebd-d5d1-40e2-bad8-10c59e1aecef@github.com>

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove -noasyncgc from com.sun.tools.example.debug.tty.TTY

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20945/files
  - new: https://git.openjdk.org/jdk/pull/20945/files/6e429eef..df9e300b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From jpai at openjdk.org  Mon Sep 16 03:56:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 03:56:40 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v3]
In-Reply-To: <E0jiKiIZ7QbdSTq9QU6ez4Ore2j_slSE3RWbOnI15KY=.3b36645e-a542-48d9-a5d6-76f275379252@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <o68So47PO0jW2drJQlMf_0fzMQFC-aUwJLZcahdUB7c=.b959f72d-26db-4db3-83f5-2a7beffcb6eb@github.com>
 <XsEeHmr_Jahj6ljbBVVjAH57y7f8RAOCtA3QvPT9PeM=.606277b2-c0ca-433d-8eaa-e546f2edc8c3@github.com>
 <E0jiKiIZ7QbdSTq9QU6ez4Ore2j_slSE3RWbOnI15KY=.3b36645e-a542-48d9-a5d6-76f275379252@github.com>
Message-ID: <sO0_76BszRFafJ90NKCtcqYlTtT2nvKG_4ovN2kqGe4=.4387f437-653d-456e-9883-95619cc93993@github.com>

On Sat, 14 Sep 2024 20:52:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/man/java.1 line 3918:
>> 
>>> 3916: option \f[V]-XX:-ScavengeBeforeFullGC\f[R].
>>> 3917: .TP
>>> 3918: \f[V]-Xfuture\f[R]
>> 
>> Maybe also remove the -X help (or at least change its description) in https://github.com/openjdk/jdk/blob/c91fa278fe17ab204beef0fcef1ada6dd0bc37bb/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L144
>
> Yes this needs to be removed from the help text.

Thank you for spotting that Bernd. I have updated the PR to remove that text as well as updated an example program that was using `-noasyncgc`. I have searched the code for other similar occurences and haven't found anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1760499899

From dholmes at openjdk.org  Mon Sep 16 04:04:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Sep 2024 04:04:09 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v5]
In-Reply-To: <-yb7cj89kQoBhTN1Y7y4FaqbiIVIrhRr47r4_485w5s=.9fb11ebd-d5d1-40e2-bad8-10c59e1aecef@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <-yb7cj89kQoBhTN1Y7y4FaqbiIVIrhRr47r4_485w5s=.9fb11ebd-d5d1-40e2-bad8-10c59e1aecef@github.com>
Message-ID: <2xpYFQE3_jk1hAT8i7gLAjDEnr7fXFBeYdfVaxosjso=.c1459be8-defc-4679-b30a-43464f48323c@github.com>

On Mon, 16 Sep 2024 03:56:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove -noasyncgc from com.sun.tools.example.debug.tty.TTY

Looks good. But another cleanup is also possible

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 991:

> 989:                    // Old-style options (These should remain in place as long as
> 990:                    //  the standard VM accepts them)
> 991:                    token.equals("-prof") ||

The `-prof` flag doesn't exist either.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20945#pullrequestreview-2305716139
PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1760502796

From jpai at openjdk.org  Mon Sep 16 04:18:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 04:18:38 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v6]
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <ggqBPPXCPyhlANhLhI9-xOm-Fp-nnX71D-y6na4wl_8=.f9147f93-a121-4445-ab45-8d1ffa28d497@github.com>

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove unsupported -v -v: and -prof from com.sun.tools.example.debug.tty.TTY

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20945/files
  - new: https://git.openjdk.org/jdk/pull/20945/files/df9e300b..4822c831

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From jpai at openjdk.org  Mon Sep 16 04:18:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 04:18:39 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v5]
In-Reply-To: <2xpYFQE3_jk1hAT8i7gLAjDEnr7fXFBeYdfVaxosjso=.c1459be8-defc-4679-b30a-43464f48323c@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <-yb7cj89kQoBhTN1Y7y4FaqbiIVIrhRr47r4_485w5s=.9fb11ebd-d5d1-40e2-bad8-10c59e1aecef@github.com>
 <2xpYFQE3_jk1hAT8i7gLAjDEnr7fXFBeYdfVaxosjso=.c1459be8-defc-4679-b30a-43464f48323c@github.com>
Message-ID: <kGSrInyPmSwpDeLPx3CGgFlrmEQlgTn2XPQR47VbZLA=.af7414ae-c5e4-4b08-82ec-b51c7e924595@github.com>

On Mon, 16 Sep 2024 03:59:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove -noasyncgc from com.sun.tools.example.debug.tty.TTY
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 991:
> 
>> 989:                    // Old-style options (These should remain in place as long as
>> 990:                    //  the standard VM accepts them)
>> 991:                    token.equals("-prof") ||
> 
> The `-prof` flag doesn't exist either.

Done. There also was `-v` and `-v:...` in this example which aren't supported either (not even in JDK 8). So I've removed those as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1760510631

From dholmes at openjdk.org  Mon Sep 16 04:31:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Sep 2024 04:31:05 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v5]
In-Reply-To: <kGSrInyPmSwpDeLPx3CGgFlrmEQlgTn2XPQR47VbZLA=.af7414ae-c5e4-4b08-82ec-b51c7e924595@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <-yb7cj89kQoBhTN1Y7y4FaqbiIVIrhRr47r4_485w5s=.9fb11ebd-d5d1-40e2-bad8-10c59e1aecef@github.com>
 <2xpYFQE3_jk1hAT8i7gLAjDEnr7fXFBeYdfVaxosjso=.c1459be8-defc-4679-b30a-43464f48323c@github.com>
 <kGSrInyPmSwpDeLPx3CGgFlrmEQlgTn2XPQR47VbZLA=.af7414ae-c5e4-4b08-82ec-b51c7e924595@github.com>
Message-ID: <LtiK6fVArzqSSs0lOsWtf-FVw-plF7SG1tD-0iTYCyQ=.a359764b-2130-4e6a-86a5-1f50f52c4c87@github.com>

On Mon, 16 Sep 2024 04:15:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 991:
>> 
>>> 989:                    // Old-style options (These should remain in place as long as
>>> 990:                    //  the standard VM accepts them)
>>> 991:                    token.equals("-prof") ||
>> 
>> The `-prof` flag doesn't exist either.
>
> Done. There also was `-v` and `-v:...` in this example which aren't supported either (not even in JDK 8). So I've removed those as well.

What about:

                 token.startsWith("-ms") || token.startsWith("-mx") ||
                   token.startsWith("-ss") || token.startsWith("-oss") ) {

? `-oss` is gone as of 9. The others are not need as the -X counterpart can be used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1760517430

From jpai at openjdk.org  Mon Sep 16 04:37:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 04:37:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v5]
In-Reply-To: <LtiK6fVArzqSSs0lOsWtf-FVw-plF7SG1tD-0iTYCyQ=.a359764b-2130-4e6a-86a5-1f50f52c4c87@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <-yb7cj89kQoBhTN1Y7y4FaqbiIVIrhRr47r4_485w5s=.9fb11ebd-d5d1-40e2-bad8-10c59e1aecef@github.com>
 <2xpYFQE3_jk1hAT8i7gLAjDEnr7fXFBeYdfVaxosjso=.c1459be8-defc-4679-b30a-43464f48323c@github.com>
 <kGSrInyPmSwpDeLPx3CGgFlrmEQlgTn2XPQR47VbZLA=.af7414ae-c5e4-4b08-82ec-b51c7e924595@github.com>
 <LtiK6fVArzqSSs0lOsWtf-FVw-plF7SG1tD-0iTYCyQ=.a359764b-2130-4e6a-86a5-1f50f52c4c87@github.com>
Message-ID: <hKxrR1xut0xNVnreuFSwONHzJlhwoPcV0qbyvkA3BzE=.df8521b3-e58f-4b2a-b26c-b50fecca97be@github.com>

On Mon, 16 Sep 2024 04:28:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Done. There also was `-v` and `-v:...` in this example which aren't supported either (not even in JDK 8). So I've removed those as well.
>
> What about:
> 
>                  token.startsWith("-ms") || token.startsWith("-mx") ||
>                    token.startsWith("-ss") || token.startsWith("-oss") ) {
> 
> ? `-oss` is gone as of 9. The others are not need as the -X counterpart can be used.

One of my next plans, as part of the launcher options cleanup https://bugs.openjdk.org/browse/JDK-8286851, was to create a task to deprecate for removal -ms and -mx. I was thinking of removing these usage in this code, as part of that effort. But yes, I can remove these options from this example here as part of this PR - I'll go ahead and do it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20945#discussion_r1760520434

From jpai at openjdk.org  Mon Sep 16 04:44:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 04:44:39 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v7]
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove usage of -ms -mx -ss and -oss from com.sun.tools.example.debug.tty.TTY

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20945/files
  - new: https://git.openjdk.org/jdk/pull/20945/files/4822c831..8cdf5627

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20945&range=05-06

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20945/head:pull/20945

PR: https://git.openjdk.org/jdk/pull/20945

From dholmes at openjdk.org  Mon Sep 16 05:04:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Sep 2024 05:04:04 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v7]
In-Reply-To: <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>
Message-ID: <NZZPi6sE1mCnnPaLTFieC4KdTeuKtWOyw7HtLAb7Paw=.7ba70426-bd6e-4809-869b-5a8c7f19348c@github.com>

On Mon, 16 Sep 2024 04:44:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove usage of -ms -mx -ss and -oss from com.sun.tools.example.debug.tty.TTY

Ship it! :)

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20945#pullrequestreview-2305746316

From jpai at openjdk.org  Mon Sep 16 06:19:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 06:19:05 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v2]
In-Reply-To: <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
Message-ID: <_ynbCEj7_y5ENjXcozIZEomPDaUU__0469rLSp4EVrU=.1b359a4c-7fdb-42d0-ac77-29e3fe6d3308@github.com>

On Mon, 16 Sep 2024 01:08:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typos
>
> src/java.base/share/native/libjli/java.c line 38:
> 
>> 36:  * One job of the launcher is to remove command line options which the
>> 37:  * vm does not understand and will not process. These options include
>> 38:  * options which select which style of vm is run (e.g. -client and
> 
> Aren't these the only options now?

Right now, in mainline, the launcher code in `CheckJvmType` function additionally also checks for the presence of `-XXaltjvm` launcher option. Just like for `-server`, `-client` options, this `CheckJvmType` function also strips the `-XXaltjvm` option from the options that are passed along to the JVM.

Specifically, in mainline, right now the following appears to be functional:


<JDK_24>/bin/java -XXaltjvm=<JDK_22>/lib/server/  -version

will load and print the Java 22 VM output:


openjdk version "22" 2024-03-19
OpenJDK Runtime Environment (build 22+36-2370)
OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)


i.e. the launcher from mainline JDK launches the altjvm from JDK 22. `CheckJvmType` in the launcher code, is where this parsing and stripping of `-XXaltjvm` is currently happening. 

(There's also some hotspot VM side code which appears to be parsing a `-Dsun.java.launcher.is_altjvm=` option to detect this `-XXaltjvm` usage, but as far as I can see the launcher no where sets this `-Dsun.java.launcher.is_altjvm=` when `-XXaltjvm` is used. So, I think, this needs a separate investigation of its own)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760584301

From alanb at openjdk.org  Mon Sep 16 06:24:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Sep 2024 06:24:05 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v7]
In-Reply-To: <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>
Message-ID: <TzPejy16KOgj7rwuaZc8TB9IxQ1q_uKxADQMJz0Hb1A=.3981eeed-f0d3-4645-9e16-f10667fe49b9@github.com>

On Mon, 16 Sep 2024 04:44:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove usage of -ms -mx -ss and -oss from com.sun.tools.example.debug.tty.TTY

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20945#pullrequestreview-2305812292

From jpai at openjdk.org  Mon Sep 16 06:52:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 06:52:40 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v3]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <caenNGsHCoANwnLGoXI3wtQCpKx2J4uLMYXS1zu9dFc=.ec44e707-d6df-43cb-a6ac-7392b7c5f733@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  fix code comment style where appropriate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/0db4faf3..84135eff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=01-02

  Stats: 25 lines in 3 files changed: 0 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From jpai at openjdk.org  Mon Sep 16 06:52:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 06:52:40 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v3]
In-Reply-To: <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
Message-ID: <r6BmK1d9dAuB7Al1ibHdtHeQJkgi_03YqYiIpdXLohc=.a1afd194-92db-4d0f-b617-194531383d44@github.com>

On Mon, 16 Sep 2024 01:17:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix code comment style where appropriate
>
> src/java.base/share/native/libjli/java.c line 1421:
> 
>> 1419: ) {
>> 1420: 
>> 1421:     // command line specified "-splash:" takes priority over manifest one.
> 
> General comment on comment style. Comments should either be written like sentences and start with a Capital and end with a period; or have neither.

I have now updated this PR to follow this suggestion for the new/updated code comments that were introduced in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760613901

From epeter at openjdk.org  Mon Sep 16 07:51:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Sep 2024 07:51:15 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
Message-ID: <0Ak63KM4JYdbOT33Q8XPcv096MKzjY6vyl4xZkapZwM=.6b92e423-9bd5-4109-a0b3-75dbeaf40315@github.com>

On Mon, 16 Sep 2024 02:58:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.

Looks better, I still have a few comments.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2739:

> 2737:   return true;
> 2738: }
> 2739: 

@jatin-bhateja You still have 3x `unbox failed v1` here. I already commented this earlier, and you resolved it and gave it a thumbs up ? 
Can you please fix it now?

src/hotspot/share/opto/vectornode.cpp line 2116:

> 2114:   const TypeVect* index_vect_type = index_vec->bottom_type()->is_vect();
> 2115:   BasicType index_elem_bt = index_vect_type->element_basic_type();
> 2116:   assert(!is_floating_point_type(index_elem_bt), "");

Why not verify this also in the constructor of `SelectFromTwoVectorNode`? Can you maybe explicitly verify what it must be rather than **not** be?

src/hotspot/share/opto/vectornode.cpp line 2122:

> 2120:   // index format by subsequent VectorLoadShuffle.
> 2121:   int cast_vopc = VectorCastNode::opcode(0, index_elem_bt, true);
> 2122:   Node* index_byte_vec = phase->transform(VectorCastNode::make(cast_vopc, index_vec, T_BYTE, num_elem));

This cast assumes that the indices cannot have more than 8 bits. This would allow vector lengths of up to 256. This is fine for intel. But as far as I know ARM has in principle longer vectors - up to 2048 bytes. Should we maybe add some assert here to make sure we never badly truncate the index?

src/hotspot/share/opto/vectornode.cpp line 2138:

> 2136: 
> 2137:   // Load indexes from byte vector and appropriatly massage them to target specific
> 2138:   // permutation index format.

I would replace `massage` -> `transform` everywhere.

src/hotspot/share/opto/vectornode.hpp line 1625:

> 1623:   Node* Ideal(PhaseGVN* phase, bool can_reshape);
> 1624:   virtual int Opcode() const;
> 1625: };

`index` -> `indexes` because this is a vector, right? Otherwise I'll assume it is a scalar.
Can you do some pseudo-code, that says how exactly the indices are interpreted? What if they are out of bounds? Does it wrap? Or assume they are in bounds? Undefined behaviour?

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2305905569
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760651336
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760674461
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760678107
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760680772
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760665944

From epeter at openjdk.org  Mon Sep 16 07:51:16 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Sep 2024 07:51:16 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
Message-ID: <AgbqqlGF_TyM-5b4Zap10S1iLahRjwL-Kiq1vKJglyA=.c3809925-60f9-469f-a3e1-ae2b2c593f1a@github.com>

On Fri, 30 Aug 2024 14:44:05 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding descriptive comments
>
> src/hotspot/share/opto/vectornode.cpp line 2104:
> 
>> 2102:   //         MASK)
>> 2103:   // This shall prevent an intrinsification failure and associated argument
>> 2104:   // boxing penalties.
> 
> A quick comment about how the mask is computed could be nice.
> `MASK = INDEX < num_elem`

@jatin-bhateja very nice, thanks!

> src/hotspot/share/opto/vectornode.cpp line 2148:
> 
>> 2146: 
>> 2147:   BoolTest::mask pred = BoolTest::lt;
>> 2148:   ConINode* pred_node = (ConINode*)phase->makecon(TypeInt::make(pred));
> 
> Would `as_ConI()` be a better alternative to the `(ConINode*)` cast?

Please at least add a comment why you are not following my suggestion. I feel like the work I put in to review is not being respected when comments are just silently resolved without any action or comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760673419
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760656304

From epeter at openjdk.org  Mon Sep 16 07:51:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Sep 2024 07:51:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <AgbqqlGF_TyM-5b4Zap10S1iLahRjwL-Kiq1vKJglyA=.c3809925-60f9-469f-a3e1-ae2b2c593f1a@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <AgbqqlGF_TyM-5b4Zap10S1iLahRjwL-Kiq1vKJglyA=.c3809925-60f9-469f-a3e1-ae2b2c593f1a@github.com>
Message-ID: <SKSw-FrhZoxCgHq1c5Nf361hGzjhHeAqAQrTTAXPJQM=.19c4f7aa-ded9-42ee-888f-58e8863fa65d@github.com>

On Mon, 16 Sep 2024 07:27:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2148:
>> 
>>> 2146: 
>>> 2147:   BoolTest::mask pred = BoolTest::lt;
>>> 2148:   ConINode* pred_node = (ConINode*)phase->makecon(TypeInt::make(pred));
>> 
>> Would `as_ConI()` be a better alternative to the `(ConINode*)` cast?
>
> Please at least add a comment why you are not following my suggestion. I feel like the work I put in to review is not being respected when comments are just silently resolved without any action or comment.

I really do think that `as_ConI()` would be the right thing here. In product it is just a cast, and in debug at least we have an assert.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760657072

From epeter at openjdk.org  Mon Sep 16 07:51:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Sep 2024 07:51:18 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <0Ak63KM4JYdbOT33Q8XPcv096MKzjY6vyl4xZkapZwM=.6b92e423-9bd5-4109-a0b3-75dbeaf40315@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
 <0Ak63KM4JYdbOT33Q8XPcv096MKzjY6vyl4xZkapZwM=.6b92e423-9bd5-4109-a0b3-75dbeaf40315@github.com>
Message-ID: <4VKGFHuL8RSSll0Pnqgg5DeesBdXys8JOZT64yGUBG8=.58b88db6-58c0-49ea-b01c-d2d814a93cae@github.com>

On Mon, 16 Sep 2024 07:35:46 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
>
> src/hotspot/share/opto/vectornode.hpp line 1625:
> 
>> 1623:   Node* Ideal(PhaseGVN* phase, bool can_reshape);
>> 1624:   virtual int Opcode() const;
>> 1625: };
> 
> `index` -> `indexes` because this is a vector, right? Otherwise I'll assume it is a scalar.
> Can you do some pseudo-code, that says how exactly the indices are interpreted? What if they are out of bounds? Does it wrap? Or assume they are in bounds? Undefined behaviour?

For me good comments here would be immendely valuable, because it helps with other C2 optimizations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760667297

From epeter at openjdk.org  Mon Sep 16 07:51:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Sep 2024 07:51:18 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <O757o3aig_rEnL3ZedwJwXrol51JVmGQKAMLFtiYjtU=.671debb0-d536-4e8b-93d6-f23d4f3fd48b@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
 <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>
 <O757o3aig_rEnL3ZedwJwXrol51JVmGQKAMLFtiYjtU=.671debb0-d536-4e8b-93d6-f23d4f3fd48b@github.com>
Message-ID: <_U2DgK6DAW3ZJhozsMhwHzggUFpj5fnHdLJOoYFcNJA=.1875811f-458f-4834-bb94-339a8ff7360d@github.com>

On Fri, 13 Sep 2024 17:38:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> That does not answer my question. If the backend operations you implemented would have the wrong vector-length: do we have any tests that would catch that? Often that requires not just going "up" with a loop but also "counting down" with the loop iv. Do you know what I mean?
>
> Patch includes tests for all the species (combination of vector type and sizes), each vector kernel is validated against equivalent scalar implementation, scenario which you are referring is implicitly handled though tests.

Ok, just so that I can relax, can you please point me to this test that would implicitly verify that the backend has chosen the correct vector size?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1760671393

From redestad at openjdk.org  Mon Sep 16 07:58:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Sep 2024 07:58:44 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v6]
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>

> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Translate to int flags at edge, avoiding TOCTOU and simplifying trusted callers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21002/files
  - new: https://git.openjdk.org/jdk/pull/21002/files/62a88c03..0d97f165

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=04-05

  Stats: 32 lines in 3 files changed: 6 ins; 9 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21002/head:pull/21002

PR: https://git.openjdk.org/jdk/pull/21002

From redestad at openjdk.org  Mon Sep 16 07:58:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Sep 2024 07:58:44 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v5]
In-Reply-To: <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <3aKQsBPlkK-k05eHoZFxftXioHsS3WyRR67eWpNJOAI=.7b98cff8-ac36-4270-a7af-a419e1165c45@github.com>
Message-ID: <YIToB-zrtG7gMAPiE2qWqxlZEzDY3LXwXRjv3QoYzBE=.0aa9c875-16aa-41d9-b8e7-3ff355f2c128@github.com>

On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve edge invariant checks

How about this: We add validation to `ClassOption::optionsToFlag` and translate at the public API entry points, then use `int flags` in all internal and private methods. This keeps validation sane and TOCTOU-free and reduces overhead for internal callers even further since we just pass a constant flag mask. 

Also avoids loading `ClassOption` on startup tests since we don't go through the public API for internal code generators.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21002#issuecomment-2352235785

From jpai at openjdk.org  Mon Sep 16 08:38:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 08:38:10 GMT
Subject: Integrated: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher
In-Reply-To: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
Message-ID: <9ga2eLyFDwFxfGUjJt4G4IzdMq7wBoZgOqG1zYjTCsc=.8552dc43-f641-4d85-9cf2-089c379368b8@github.com>

On Wed, 11 Sep 2024 09:47:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
> 
> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
> 
> Would this change require a CSR?

This pull request has now been integrated.

Changeset: a4eb9a06
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a4eb9a063fb9e4a87923d464fe2c50ed5466acff
Stats:     38 lines in 4 files changed: 10 ins; 25 del; 3 mod

8339918: Remove checks for outdated -t -tm -Xfuture -checksource -cs -noasyncgc options from the launcher

Reviewed-by: dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20945

From jpai at openjdk.org  Mon Sep 16 08:38:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 08:38:09 GMT
Subject: RFR: 8339918: Remove checks for outdated -t -tm -Xfuture
 -checksource -cs -noasyncgc options from the launcher [v7]
In-Reply-To: <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>
References: <7MNA8q31xVHX7rE1h5VF-fkzKW0_5y98LB_zvL2MlJ0=.c0666a26-372f-466a-89b7-5d89a59c8275@github.com>
 <Q2o_Xu51tT8yWFYRVAliprX_EVO-AXFZ79j7MLBv2Vg=.84d82d64-aa60-4262-a6be-0134ae8dec6c@github.com>
Message-ID: <ZMR6U6GHhg0tFxz0X5suBztBamXDkJwqMCglrhpWQPA=.e51b8b6e-5fa7-4723-859c-9445262ce486@github.com>

On Mon, 16 Sep 2024 04:44:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which cleans up the `java` launcher to remove checks/support for outdated options?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have been outdated and unsupported for several releases now. 2 of them even throw an error currently. The change in this PR removes the code which had specific checks for these options and will now consider these options just like any other unknown option to the launcher.
>> 
>> tier1, tier2 and tier3 testing passed with these changes. Higher tier testing is in progress.
>> 
>> Would this change require a CSR?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove usage of -ms -mx -ss and -oss from com.sun.tools.example.debug.tty.TTY

Thank you Alan and David for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20945#issuecomment-2352304904

From jpai at openjdk.org  Mon Sep 16 08:49:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 08:49:52 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v4]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <BKQd18Z6JSAWWeddZArlw0anDMCBmJXzGSiPFd1FShc=.9373ca4d-7119-4a7f-b7bf-15f852b1cb57@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai 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 latest from master branch
 - fix code comment style where appropriate
 - typos
 - 8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/84135eff..2f09c153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=02-03

  Stats: 3762 lines in 86 files changed: 2246 ins; 966 del; 550 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From eirbjo at openjdk.org  Mon Sep 16 09:23:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Sep 2024 09:23:05 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
Message-ID: <I-nldD3z6DAjdH2A0Ukc8l6vuTD1zjSUyTJ7Q4er7dM=.e6b20575-4d8f-455b-8ae9-8d1e681714eb@github.com>

On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @link ->@linkplain

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 381:

> 379:      * the underlying stream. Use this method when applying multiple filters
> 380:      * in succession to the same output stream.
> 381:      * <p>

People reading this not too carefully may think the combined length referrs to the concatenated string length. I know "bytes" is the last word, so technically this is correct. But maybe being slightly more explicit that the length depends on the chosen charset would remove some ambiguity?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1760803539

From jpai at openjdk.org  Mon Sep 16 09:27:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 09:27:38 GMT
Subject: RFR: 8340176: Replace usage of -noclassgc with -Xnoclassgc in
 test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
Message-ID: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>

Can I please get a review of this test-only change which replaces the usage of `-noclassgc` with `-Xnoclassgc` option when launching the test?

As noted in https://bugs.openjdk.org/browse/JDK-8340176, the `-noclassgc` is an undocumented option of the `java` launcher, which it converts to `-Xnoclassgc` before passing it to the JVM. Instead of that option, the documented `-Xnoclassgc` should be used.

No new test has been introduced and the modified test continues to pass after this change.

-------------

Commit messages:
 - 8340176: Replace usage of -noclassgc with -Xnoclassgc in test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java

Changes: https://git.openjdk.org/jdk/pull/21012/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340176
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21012.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21012/head:pull/21012

PR: https://git.openjdk.org/jdk/pull/21012

From kevinw at openjdk.org  Mon Sep 16 09:39:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Sep 2024 09:39:09 GMT
Subject: RFR: 8340176: Replace usage of -noclassgc with -Xnoclassgc in
 test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
In-Reply-To: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
References: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
Message-ID: <SVsgZxTKujnSXK_cNLwTR4JjCXi3lmVlTjZh9AQjnHE=.63cba346-3cd0-4900-963f-f42e4ebe8bfa@github.com>

On Mon, 16 Sep 2024 09:21:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usage of `-noclassgc` with `-Xnoclassgc` option when launching the test?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340176, the `-noclassgc` is an undocumented option of the `java` launcher, which it converts to `-Xnoclassgc` before passing it to the JVM. Instead of that option, the documented `-Xnoclassgc` should be used.
> 
> No new test has been introduced and the modified test continues to pass after this change.

Looks good, thanks  8-)

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21012#pullrequestreview-2306160592

From asotona at openjdk.org  Mon Sep 16 09:41:46 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Sep 2024 09:41:46 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v4]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <kAaIGpyJT28MdMcL9seX5mzfKJjOtnUYPdLqjoGtEe8=.2b70faac-2a32-460e-a7f1-286e43d461ef@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

-------------

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=03
  Stats: 718 lines in 165 files changed: 0 ins; 480 del; 238 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

PR: https://git.openjdk.org/jdk/pull/19826

From eirbjo at openjdk.org  Mon Sep 16 09:42:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Sep 2024 09:42:06 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
Message-ID: <NRsNgdaAXzhnFLJekkViqPUqcXdi3if8h3vzNIeVkPQ=.0e310322-168c-4416-846a-81b4a74b96a4@github.com>

On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @link ->@linkplain

src/java.base/share/classes/java/util/zip/ZipEntry.java line 41:

> 39:  * This class is used to represent a ZIP file entry.
> 40:  * <P>
> 41:  * The combined length of the entry name, the extra field data, the

"bytes" is the last word here, so technically this is correct. But an external reader may easily think this refers to the string lengths, not the byte encoded lengths.

So  maybe being slightly more explicit that the encoded length depends on the chosen charset would reduce ambiguity?

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 642:

> 640:         if (e.comment != null) {
> 641:             commentBytes = zc.getBytes(e.comment);
> 642:             clen = Math.min(commentBytes.length, 0xffff);

Moving the headerLength validation earlier in the method would remove the need to this comment truncation, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1760825827
PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1760828839

From asotona at openjdk.org  Mon Sep 16 09:59:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Sep 2024 09:59:40 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v5]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <SMCHT3gn--56kq0MrvB5sSbiVfUx73vzcRlxm68EcFw=.59bc3b5a-795c-407a-b714-e00f76bc077e@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

-------------

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=04
  Stats: 718 lines in 165 files changed: 0 ins; 480 del; 238 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

PR: https://git.openjdk.org/jdk/pull/19826

From eirbjo at openjdk.org  Mon Sep 16 10:08:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Sep 2024 10:08:05 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
Message-ID: <ewyA7EVHOTG9ZafU_iWO5JiF8nWEN6PcWdwAJ2S9F48=.563b0a55-af1e-43ca-99c6-570807925481@github.com>

On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @link ->@linkplain

I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?

Also, since the combined header length clause applies to "any directory record", it also applies to LOC?

So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?

Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile. 

Some comments inline.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21003#pullrequestreview-2306219878

From alanb at openjdk.org  Mon Sep 16 10:15:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Sep 2024 10:15:06 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v4]
In-Reply-To: <BKQd18Z6JSAWWeddZArlw0anDMCBmJXzGSiPFd1FShc=.9373ca4d-7119-4a7f-b7bf-15f852b1cb57@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <BKQd18Z6JSAWWeddZArlw0anDMCBmJXzGSiPFd1FShc=.9373ca4d-7119-4a7f-b7bf-15f852b1cb57@github.com>
Message-ID: <j6L0dt7qwOmqqn5QkfiN7-pvOvr_OEbe8J2Srffn8bk=.3fcb1587-c950-4753-8a00-c21890c89a0b@github.com>

On Mon, 16 Sep 2024 08:49:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai 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 latest from master branch
>  - fix code comment style where appropriate
>  - typos
>  - 8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow

src/java.base/macosx/native/libjli/java_md_macosx.m line 108:

> 106:  *
> 107:  *  - JavaMain then returns back an integer result which then gets propagated as a return value all the way out
> 108:  *    of the JLI_Launch function.

Are you going to re-flow this comment block o reduce the line lengths, the really long lines are real bitlly annoying for side-by-side diffs and also inconsistent with the rest of the file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760873433

From duke at openjdk.org  Mon Sep 16 10:22:05 2024
From: duke at openjdk.org (Kasper Nielsen)
Date: Mon, 16 Sep 2024 10:22:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
Message-ID: <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>

On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |             10255 |           10154 |
>> | AtomicBoolean.class                   |              5364 |             5161 |
>> |AtomicMarkableReference.class |              3890 |            3687 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |        5963657 |
>> | Patch                |        5962751 |
>> | Delta                 |                906|
>> 
>> For 60 billion instances, this represents 54 TB.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename and reformat

This would actually be super useful in a public API. I use the same "trick" in some of my projects. Not because I care too much about the classfile size. But it is just a lot easier on the eye.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2352521927

From ihse at openjdk.org  Mon Sep 16 10:22:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Sep 2024 10:22:11 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <ysPh_tERSmx4F3ZI7mBwohjrHZe9QMUIlU5SNzAtcII=.dec773cc-5b3c-4670-b31b-d86397d7fa71@github.com>

On Fri, 13 Sep 2024 20:41:27 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

Make changes look fine now.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2306245227

From jpai at openjdk.org  Mon Sep 16 11:10:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 11:10:28 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v5]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <tJpbUVwKYZiaCdICqa3e3NKOtYVAHas1JaYfzkn4kN8=.c21a5312-1bc8-446d-aea1-597e03555985@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  reduce code comment line lengths

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/2f09c153..c703f779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=03-04

  Stats: 126 lines in 2 files changed: 52 ins; 0 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From jpai at openjdk.org  Mon Sep 16 11:10:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 11:10:30 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v4]
In-Reply-To: <j6L0dt7qwOmqqn5QkfiN7-pvOvr_OEbe8J2Srffn8bk=.3fcb1587-c950-4753-8a00-c21890c89a0b@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <BKQd18Z6JSAWWeddZArlw0anDMCBmJXzGSiPFd1FShc=.9373ca4d-7119-4a7f-b7bf-15f852b1cb57@github.com>
 <j6L0dt7qwOmqqn5QkfiN7-pvOvr_OEbe8J2Srffn8bk=.3fcb1587-c950-4753-8a00-c21890c89a0b@github.com>
Message-ID: <bYmPF1jkil7grGpoOHHD9I1xNpjbDByI8Rvv-sBWFMc=.f468d15b-2ca6-44b0-8f0d-2b6e93588e9b@github.com>

On Mon, 16 Sep 2024 10:11:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai 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 latest from master branch
>>  - fix code comment style where appropriate
>>  - typos
>>  - 8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow
>
> src/java.base/macosx/native/libjli/java_md_macosx.m line 108:
> 
>> 106:  *
>> 107:  *  - JavaMain then returns back an integer result which then gets propagated as a return value all the way out
>> 108:  *    of the JLI_Launch function.
> 
> Are you going to re-flow this comment block o reduce the line lengths, the really long lines are a bit annoying for side-by-side diffs and also inconsistent with the rest of the file.

Hello Alan, I just pushed a update to the PR to reduce the line length of these comments. I'm hoping this reads better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1760947736

From lancea at openjdk.org  Mon Sep 16 11:35:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 11:35:10 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
Message-ID: <cAgJ9EoCF6eD0-Ze8THjZYvLOwnLn2oR2lVTV0ui4ag=.cad5b528-5c8f-4ed3-8760-22f7a30dde0f@github.com>

On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @link ->@linkplain

Thank you as always for your input Eirik, see below

-------------

PR Review: https://git.openjdk.org/jdk/pull/21003#pullrequestreview-2306363081

From lancea at openjdk.org  Mon Sep 16 11:35:11 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 11:35:11 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <NRsNgdaAXzhnFLJekkViqPUqcXdi3if8h3vzNIeVkPQ=.0e310322-168c-4416-846a-81b4a74b96a4@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <NRsNgdaAXzhnFLJekkViqPUqcXdi3if8h3vzNIeVkPQ=.0e310322-168c-4416-846a-81b4a74b96a4@github.com>
Message-ID: <ZPI3etSj1iahuh0oaZKWvB5vQR3yDygAg4W6Z9nSJv8=.ebca96e7-f243-40f3-b55b-dac2ecbae907@github.com>

On Mon, 16 Sep 2024 09:36:49 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update @link ->@linkplain
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 41:
> 
>> 39:  * This class is used to represent a ZIP file entry.
>> 40:  * <P>
>> 41:  * The combined length of the entry name, the extra field data, the
> 
> "bytes" is the last word here, so technically this is correct. But an external reader may easily think this refers to the string lengths, not the byte encoded lengths.
> 
> So  maybe being slightly more explicit that the encoded length depends on the chosen charset would reduce ambiguity?

I am not sure it is needed, but could tweak to 

> The combined length, after encoding, of the ......

thoughts?

> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 642:
> 
>> 640:         if (e.comment != null) {
>> 641:             commentBytes = zc.getBytes(e.comment);
>> 642:             clen = Math.min(commentBytes.length, 0xffff);
> 
> Moving the headerLength enforcement earlier in the method would remove the need for this comment truncation, right?

I left that intentionally for now.  A follow on PR will be updating the ZipEntry javadoc to reduce the max size of the validation check once this PR is finalized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1760977017
PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1760962573

From lancea at openjdk.org  Mon Sep 16 11:45:04 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 11:45:04 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <ewyA7EVHOTG9ZafU_iWO5JiF8nWEN6PcWdwAJ2S9F48=.563b0a55-af1e-43ca-99c6-570807925481@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <ewyA7EVHOTG9ZafU_iWO5JiF8nWEN6PcWdwAJ2S9F48=.563b0a55-af1e-43ca-99c6-570807925481@github.com>
Message-ID: <z21xVtgxymCMmCB1aTAQ5f6sRe6WmXbx5-BIqK210ek=.aa4f2a88-bc06-4cf7-babe-4013331355d5@github.com>

On Mon, 16 Sep 2024 10:05:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?
> 
> Also, since the combined header length clause applies to "any directory record", it also applies to LOC?
> 
> So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?
> 
> Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile.
> 
> Some comments inline.

As this is really a corner case at best, I decided to keep the changes to a minimum and the validation in writeCEN given that is where the encoded comment bytes are obtained and written out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21003#issuecomment-2352684425

From pminborg at openjdk.org  Mon Sep 16 12:01:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 16 Sep 2024 12:01:26 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.

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 five additional commits since the last revision:

 - Move to new package and add overload
 - Merge branch 'master' into internal-mh-util
 - Rename and reformat
 - Fix copyright headers
 - Introduce MethodHandlesInternal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/1dee24ab..e2e935b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=01-02

  Stats: 9768 lines in 215 files changed: 6742 ins; 1600 del; 1426 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From eirbjo at openjdk.org  Mon Sep 16 12:02:07 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Sep 2024 12:02:07 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <ZPI3etSj1iahuh0oaZKWvB5vQR3yDygAg4W6Z9nSJv8=.ebca96e7-f243-40f3-b55b-dac2ecbae907@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <NRsNgdaAXzhnFLJekkViqPUqcXdi3if8h3vzNIeVkPQ=.0e310322-168c-4416-846a-81b4a74b96a4@github.com>
 <ZPI3etSj1iahuh0oaZKWvB5vQR3yDygAg4W6Z9nSJv8=.ebca96e7-f243-40f3-b55b-dac2ecbae907@github.com>
Message-ID: <KZP2gxX4Y64gk5dRCTaQJxp066PsMBeUniLLEqtwLGY=.0a775758-ddb3-4e61-bd64-698da98e668f@github.com>

On Mon, 16 Sep 2024 11:31:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > The combined length, after encoding, of the ......
> 
> thoughts?

I like it. Disambiguating but also succinct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761014094

From dholmes at openjdk.org  Mon Sep 16 12:12:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Sep 2024 12:12:06 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v5]
In-Reply-To: <_ynbCEj7_y5ENjXcozIZEomPDaUU__0469rLSp4EVrU=.1b359a4c-7fdb-42d0-ac77-29e3fe6d3308@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
 <_ynbCEj7_y5ENjXcozIZEomPDaUU__0469rLSp4EVrU=.1b359a4c-7fdb-42d0-ac77-29e3fe6d3308@github.com>
Message-ID: <32XI0RxHNZiwyCFv5chF0dTNzV8427Z0kYSeLE5xC7A=.85fdeecf-9888-477f-9722-50e1d916033e@github.com>

On Mon, 16 Sep 2024 06:16:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 38:
>> 
>>> 36:  * One job of the launcher is to remove command line options which the
>>> 37:  * vm does not understand and will not process. These options include
>>> 38:  * options which select which style of vm is run (e.g. -client and
>> 
>> Aren't these the only options now?
>
> Right now, in mainline, the launcher code in `CheckJvmType` function additionally also checks for the presence of `-XXaltjvm` launcher option. Just like for `-server`, `-client` options, this `CheckJvmType` function also strips the `-XXaltjvm` option from the options that are passed along to the JVM.
> 
> Specifically, in mainline, right now the following appears to be functional:
> 
> 
> <JDK_24>/bin/java -XXaltjvm=<JDK_22>/lib/server/  -version
> 
> will load and print the Java 22 VM output:
> 
> 
> openjdk version "22" 2024-03-19
> OpenJDK Runtime Environment (build 22+36-2370)
> OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)
> 
> 
> i.e. the launcher from mainline JDK launches the altjvm from JDK 22. `CheckJvmType` in the launcher code, is where this parsing and stripping of `-XXaltjvm` is currently happening. 
> 
> (There's also some hotspot VM side code which appears to be parsing a `-Dsun.java.launcher.is_altjvm=` option to detect this `-XXaltjvm` usage, but as far as I can see the launcher no where sets this `-Dsun.java.launcher.is_altjvm=` when `-XXaltjvm` is used. So, I think, this needs a separate investigation of its own)

The property is used by the gtest launcher - see comments in [JDK-8171508](https://bugs.openjdk.org/browse/JDK-8171508)

This is all a lot more complicated than I had thought it was.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1761027867

From eirbjo at openjdk.org  Mon Sep 16 12:19:04 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Sep 2024 12:19:04 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <ZPI3etSj1iahuh0oaZKWvB5vQR3yDygAg4W6Z9nSJv8=.ebca96e7-f243-40f3-b55b-dac2ecbae907@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <NRsNgdaAXzhnFLJekkViqPUqcXdi3if8h3vzNIeVkPQ=.0e310322-168c-4416-846a-81b4a74b96a4@github.com>
 <ZPI3etSj1iahuh0oaZKWvB5vQR3yDygAg4W6Z9nSJv8=.ebca96e7-f243-40f3-b55b-dac2ecbae907@github.com>
Message-ID: <3EKp7QayzaYail3SJVTMVvvZXecwF6sh0G8Rp-QA7tc=.f4d2b356-41b7-4ac8-9014-54eb1e8e769c@github.com>

On Mon, 16 Sep 2024 11:19:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I left that intentionally for now. A follow on PR will be updating the ZipEntry javadoc to reduce the max size of the validation check once this PR is finalized.

Hang on, not sure I follow. Perhaps I just didn't understand your response..

Just to clarify my own comment first:

If the entry comment is `> 0xFFFF` at this point, then it will in all cases cause a rejection with a ZipException when the combined clause is enforced a few lines down since the comment size itself is sufficient to violate the `headerSize` check? Moving the `headerSize` validation before the comment processing would enforce the invariant that `comment < 0xFFFF - CENHDR`, thus the truncation logic would not be neccessary.

This PR documents the "combined clause" limitation in ZipEntry according to `APPNOTE.TXT`. How and why should this be reduced in the follow on PR? I don't seem to understand the scope and purpose of the follow on PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761036460

From duke at openjdk.org  Mon Sep 16 13:01:34 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 16 Sep 2024 13:01:34 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
Message-ID: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>

Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

-------------

Commit messages:
 - 8340200: Misspelled constant `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`

Changes: https://git.openjdk.org/jdk/pull/21020/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21020&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340200
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21020.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21020/head:pull/21020

PR: https://git.openjdk.org/jdk/pull/21020

From liach at openjdk.org  Mon Sep 16 13:05:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 13:05:07 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <ZI6q84xlGQ5UuUIaOLD2UQfUfiEquk0ATlnrEVGxyvk=.97fa992e-a4c6-4fb0-a206-c5021ad0d23f@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

Thanks for this typo fix. Since this will result in a signature change (technically a field removal and a field addition), this will require a short CSR. I can review both this PR and the CSR once you've created it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21020#issuecomment-2352858454

From liach at openjdk.org  Mon Sep 16 13:11:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 13:11:06 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v6]
In-Reply-To: <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>
Message-ID: <CZZIZdevWgmdw8B--lA7E0ZKWeNfvsDH9_PX_ZAffHI=.1f0df7f5-6b22-4640-8337-bf8b1fe53ff6@github.com>

On Mon, 16 Sep 2024 07:58:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Translate to int flags at edge, avoiding TOCTOU and simplifying trusted callers

Thanks! Looks much cleaner now.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21002#pullrequestreview-2306596119

From liach at openjdk.org  Mon Sep 16 13:24:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 13:24:07 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v4]
In-Reply-To: <Wn4WnQbybWxflM6QmBKikEvyyO2-pYCnJKJ3gOXd1rg=.41c6ce91-27d9-48e4-93e8-dae491aef4d1@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <Wn4WnQbybWxflM6QmBKikEvyyO2-pYCnJKJ3gOXd1rg=.41c6ce91-27d9-48e4-93e8-dae491aef4d1@github.com>
Message-ID: <hIwxrWUVMltZLL8ZrNYPw2akaRk8lSia9ArLfREQwhY=.c649a724-47f5-4070-be70-585bde668410@github.com>

On Fri, 13 Sep 2024 17:38:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename JDKUTF to ModifiedUtf
>  - suggestion from @liach

Looks good besides these 2 nitpicks. I will ask an io engineer to look at this too.

src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 1:

> 1: /*

Can add a private constructor

src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 59:

> 57:      */
> 58:     @ForceInline
> 59:     public static int utflen(String str, int countNonZeroAscii) {

maybe `utfLen` as utf and len are 2 words?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20886#pullrequestreview-2306617461
PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1761128734
PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1761132583

From jvernee at openjdk.org  Mon Sep 16 13:24:06 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 16 Sep 2024 13:24:06 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 ClassOption ... instead of Set [v6]
In-Reply-To: <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>
Message-ID: <5FfVVSQhwDvXl8wiYW-SljNDDrZonUoPHyPPPny8vY8=.dd114bb7-fde2-44b8-9fa9-202dc39425e2@github.com>

On Mon, 16 Sep 2024 07:58:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Translate to int flags at edge, avoiding TOCTOU and simplifying trusted callers

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21002#pullrequestreview-2306629187

From liach at openjdk.org  Mon Sep 16 13:36:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 13:36:04 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <prkRyizCrmG8BozX2Ng1xI7bk9UNGEey2uW9Fyw2cGQ=.dbbc9432-f64f-4301-ade6-3d5c11812d32@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

Thanks for the fix! You can transition the CSR issue state to "finalized" for review and approval.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21020#pullrequestreview-2306683545

From asotona at openjdk.org  Mon Sep 16 13:48:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Sep 2024 13:48:11 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v6]
In-Reply-To: <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
Message-ID: <87sy0INKDJwTwjtR0IBBbqowsGt4bN5jaMKvxB8v_wM=.a1c81df8-2638-4b28-bb46-48e5184f38a9@github.com>

On Sat, 14 Sep 2024 02:45:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20761#pullrequestreview-2306720423

From redestad at openjdk.org  Mon Sep 16 13:48:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Sep 2024 13:48:10 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v6]
In-Reply-To: <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
Message-ID: <RS0f3sFKvZ2Q-lBgVbGFHb-ysF2QadecL2OoLVDsxLg=.32ea0b65-ba5f-4cd6-a2bc-83be1bbf6f30@github.com>

On Sat, 14 Sep 2024 02:45:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

LGTM

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20761#pullrequestreview-2306713796

From jpai at openjdk.org  Mon Sep 16 13:55:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 13:55:49 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <_6YXev5mQRg2LEt8oWISVsx8LrwUZVG9jZP2OV0OeZQ=.52a09dcc-4d84-43d7-bc7d-ec9eaf9843cf@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  comment improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/c703f779..e0928749

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From jpai at openjdk.org  Mon Sep 16 13:55:50 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 13:55:50 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
Message-ID: <dQeeqloHkKcbCS8JJ3e2hOhl28TgWk1Z_LVeO5Mo2Rs=.756588f8-974d-4430-a98b-143f662e8ddb@github.com>

On Mon, 16 Sep 2024 01:06:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment improvements
>
> src/java.base/macosx/native/libjli/java_md_macosx.m line 83:
> 
>> 81:  *    point of creating a new thread in CreateExecutionEnvironment, the CreateExecutionEnvironment will check for
>> 82:  *    the state flag to see if a new thread has already been spawned and upon noticing that it has, it will skip
>> 83:  *    spawning any more threads and will return back from CreateExecutionEnvironment.
> 
> My understanding was that this recursive invocation was only needed when switching modes/models. I don't see why it would be needed now.

In the context of the 2 platforms - macosx and unix, the recursive invocation still continues to happen.

For macosx, the `CreateExecutionEnvironment` unconditionally, through an internal `MacOSXStartup` function, spawns a new thread (`pthread_create`). That thread is passed a function pointer pointing to the current executable/process' `main(...)` function (and thus made to execute afresh). That then triggers this recursion where `JLI_Launch` is called again and that then calls into `CreateExecutionEnvironment` all the way to `MacOSXStartup` function which has the necessary knowledge not to spawn another thread the second time.

For unix, in the `CreateExecutionEnvironment` function, there's a specific piece of code which determines whether or not `LD_LIBRARY_PATH` environment variable needs to be set or updated before loading the JVM. This decision of whether or not `LD_LIBRARY_PATH` needs to be updated or set is done in an internal function called `RequiresSetenv`. There are several rules which determine whether or not to set/update that environment variable. Rules like - is musl libc in use; or is the runtime environment AIX; or if the `LD_LIBRARY_PATH` is currently set, then whether the value in the environment variable matches some well known JVM library path patterns (like `lib/client`, `lib/server`). If any of these rules determine that the `LD_LIBRARY_PATH` needs to be set/updated, then the `CreateExecutionEnvironment` function will do the necessary updates to the environment variable value and and exec() the current process with that new value. This then triggers the recursion all the way from the `
 JLI_Launch` back into this `CreateExecutionEnvironment` (which has the necessary knowledge not to exec() once more).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1761203849

From redestad at openjdk.org  Mon Sep 16 13:58:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Sep 2024 13:58:06 GMT
Subject: RFR: 8340131: Refactor internal makeHiddenClassDefiner to take
 option mask instead of Set<ClassOption> [v6]
In-Reply-To: <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
 <uNuKzBpetGGpLkOL91qN6lQDtkgH7l0MSvMNpRCGHXQ=.6cec0563-316d-4d94-9ab9-6c2a0c2b35fd@github.com>
Message-ID: <ZwDdbEpdvJdyhPXOAjXkl9G4LYTSD3Bu5lvn0SxR6k8=.5ee6cb76-dabd-4c4a-bfeb-955633457cc4@github.com>

On Mon, 16 Sep 2024 07:58:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Translate to int flags at edge, avoiding TOCTOU and simplifying trusted callers

Thanks for reviewing. Updated title to better reflect current version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21002#issuecomment-2352997421

From jpai at openjdk.org  Mon Sep 16 14:05:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Sep 2024 14:05:06 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <dQeeqloHkKcbCS8JJ3e2hOhl28TgWk1Z_LVeO5Mo2Rs=.756588f8-974d-4430-a98b-143f662e8ddb@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
 <dQeeqloHkKcbCS8JJ3e2hOhl28TgWk1Z_LVeO5Mo2Rs=.756588f8-974d-4430-a98b-143f662e8ddb@github.com>
Message-ID: <AXQ_4yQfgalQP_ddQ_7hgL-p1z0IG7xKEmMdZF_VRZk=.0e797d2c-5f4d-47eb-9980-6bee356e3f5f@github.com>

On Mon, 16 Sep 2024 13:50:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> For macosx, the CreateExecutionEnvironment unconditionally, through an internal MacOSXStartup function, spawns a new thread (pthread_create).

I forgot to note that, the reason for spawning this new thread is explained as a code comment (unrelated to the changes in this PR) on the `MacOSXStartup` function and it says:


/*
* Mac OS X mandates that the GUI event loop run on very first thread of
* an application. This requires that we re-call Java's main() on a new
* thread, reserving the 'main' thread for Cocoa.
*/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1761227352

From redestad at openjdk.org  Mon Sep 16 14:11:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Sep 2024 14:11:10 GMT
Subject: Integrated: 8340131: Refactor internal makeHiddenClassDefiner to take
 option mask instead of Set<ClassOption>
In-Reply-To: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
References: <BpkWtyqXVpW0RmYxzAbCocMowLFMc2C3OhvL_PtoRLE=.707567cb-acbd-4354-ac0b-03b4f9779423@github.com>
Message-ID: <vxIWByQircKrvNk4teMjsa-YarjuemR7tGpXffqJkqc=.b0ca1c3e-a0f7-43f6-b718-1bb5beb095eb@github.com>

On Fri, 13 Sep 2024 15:40:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple internal refactor to load a few classes less on startup. Arguably cleaner and avoids some iterator allocations.

This pull request has now been integrated.

Changeset: e1ebeef0
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1ebeef0405ac6e48564a035767ee256291b9ca9
Stats:     48 lines in 6 files changed: 23 ins; 4 del; 21 mod

8340131: Refactor internal makeHiddenClassDefiner to take option mask instead of Set<ClassOption>

Reviewed-by: liach, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21002

From swen at openjdk.org  Mon Sep 16 14:23:52 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 16 Sep 2024 14:23:52 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v5]
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <JVD5pJEx0TJtcPBZ0NQ2_M7if91ifyRCR8J5F4zMIpw=.4b1be13e-65fa-4c79-be7b-7da3afd461a7@github.com>

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20886/files
  - new: https://git.openjdk.org/jdk/pull/20886/files/58a23d4f..83fc4685

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=03-04

  Stats: 10 lines in 4 files changed: 3 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20886/head:pull/20886

PR: https://git.openjdk.org/jdk/pull/20886

From liach at openjdk.org  Mon Sep 16 14:32:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Sep 2024 14:32:07 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v5]
In-Reply-To: <JVD5pJEx0TJtcPBZ0NQ2_M7if91ifyRCR8J5F4zMIpw=.4b1be13e-65fa-4c79-be7b-7da3afd461a7@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <JVD5pJEx0TJtcPBZ0NQ2_M7if91ifyRCR8J5F4zMIpw=.4b1be13e-65fa-4c79-be7b-7da3afd461a7@github.com>
Message-ID: <3NUUIa9rdY2Gr0HfKxsU28SYWwu_cLL1xHCf0adDB3s=.a4f7b7bc-2361-4fab-a7dd-6fb6e603eade@github.com>

On Mon, 16 Sep 2024 14:23:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

Looks good; waiting for an io engineer review.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20886#pullrequestreview-2306852928

From lmesnik at openjdk.org  Mon Sep 16 15:23:08 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 16 Sep 2024 15:23:08 GMT
Subject: RFR: 8340176: Replace usage of -noclassgc with -Xnoclassgc in
 test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
In-Reply-To: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
References: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
Message-ID: <n-c6GClEF6fsz8qPY-QBoh4qY6HGpQKoC-CWqr8mGwE=.54f0930e-9dec-4673-b28a-888f97b99bf4@github.com>

On Mon, 16 Sep 2024 09:21:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usage of `-noclassgc` with `-Xnoclassgc` option when launching the test?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340176, the `-noclassgc` is an undocumented option of the `java` launcher, which it converts to `-Xnoclassgc` before passing it to the JVM. Instead of that option, the documented `-Xnoclassgc` should be used.
> 
> No new test has been introduced and the modified test continues to pass after this change.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21012#pullrequestreview-2306989340

From sgehwolf at openjdk.org  Mon Sep 16 16:15:32 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 16 Sep 2024 16:15:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v37]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <evgEgXvc5ogxiaLtQ39DvMEblCp8e5KxXRkrsZTvefU=.2595fd56-a36c-48c3-b2a9-a1ab79157343@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 143 commits:

 - Update error message when linking jdk.jlink
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - Enable GenerateJLIClassesPluginTest.java test
 - Enable JLinkReproducibleTest.java for linkable JDK images
 - ... and 133 more: https://git.openjdk.org/jdk/compare/996790c7...182c4aa5

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=36
  Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sgibbons at openjdk.org  Mon Sep 16 16:36:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 16 Sep 2024 16:36:11 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v6]
In-Reply-To: <rwkPfk02vzVHscuFseCGUGp14yVFd7ezjUVM80cKFkY=.a38665b3-6cf9-45f2-bae1-400bf462d0a4@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <rwkPfk02vzVHscuFseCGUGp14yVFd7ezjUVM80cKFkY=.a38665b3-6cf9-45f2-bae1-400bf462d0a4@github.com>
Message-ID: <L8uQrfPpSYwFlbxBdQ9APdhFf3V2k7WYlSi8kZCxrg8=.f159fbd8-a19d-4486-9d4f-8b024536ec6a@github.com>

On Fri, 13 Sep 2024 22:36:45 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/Math/HyperbolicTests.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

I hand-verified the code.

-------------

Marked as reviewed by sgibbons (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20657#pullrequestreview-2307159316

From psandoz at openjdk.org  Mon Sep 16 16:47:11 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 16:47:11 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v2]
In-Reply-To: <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>
Message-ID: <nWNd0laNYTmT_8ztVv0gifiDhYx0qO0-0IMXqgPyeJM=.cc8bd3c1-f0c9-4dbf-b9a6-74be90ff6142@github.com>

On Fri, 13 Sep 2024 22:30:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>> 
>> Summary of changes is as follows:
>>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>> 
>> For the following source:
>> 
>> 
>>     public void test() {
>>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>>             index.selectFrom(inpvect).intoArray(byteres, j);
>>         }
>>     }
>> 
>> 
>> The code generated for inner main now looks as follows:
>> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>>   0x00007f40d02274d0:   movslq %ebx,%r13
>>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>>   0x00007f40d022751f:   add    $0x40,%ebx
>>   0x00007f40d0227522:   cmp    %r8d,%ebx
>>   0x00007f40d0227525:   jl     0x00007f40d02274d0
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Java changes are good (I created a CSR). The approach in HotSpot looks good to me, but need HotSpot reviewers.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20634#pullrequestreview-2307180561

From sviswanathan at openjdk.org  Mon Sep 16 17:02:09 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 16 Sep 2024 17:02:09 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <GwQIFcz4V6pibMfRxVAqOyUrOmgE9iwkzNItZVaY6j8=.de6221ba-8ef8-4773-a9aa-11b07e9fa456@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <L3raQIsBWTc504BaXOu5vM0JbmlPKywyLzbbb6mD8dg=.88612fb2-b53a-4a1b-9538-daaeaca66d9d@github.com>
 <gFiugusEK31pCIqMQgnlNSGQLhykQjPBbUoxzLcGpG8=.a5a333b3-44a5-4657-b9f9-3d7f51d6229a@github.com>
 <GwQIFcz4V6pibMfRxVAqOyUrOmgE9iwkzNItZVaY6j8=.de6221ba-8ef8-4773-a9aa-11b07e9fa456@github.com>
Message-ID: <0QUwAu8wCrqU-BSbINCiBATZje4xib3rLEZKgG9mHhE=.fed2bc28-b4c3-417d-b4d6-3b5ce1e34c67@github.com>

On Fri, 13 Sep 2024 19:45:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> Given `rearrange` with 1 vector gets wrapping indices semantics. I think we should stop normalizing indices when converting a `Vector` into a `VectorShuffle` (currently we wrap all out-of-bound elements to `[-VLEN, 0)`). Then the rearrange with 2 vectors will also wrap similarly (all indices are `& (VLEN * 2 - 1)`, then indices `[0, VLEN)` maps to the first vector and indices `[VLEN, 2 * VLEN)` map to the second vector). We will normalize the indices when we invoke `VectorShuffle::toVector` which I think is much less used than `Vector::toShuffle`. What do you think?
>> 
>> The guidance from Paul Sandoz and John Rose is to keep the the partial wrapping at shuffle construction as is for now and only change the rearrange and selectFrom apis.
>
>> 
>> The guidance from Paul Sandoz and John Rose is to keep the the partial wrapping at shuffle construction as is for now and only change the rearrange and selectFrom apis.
> 
> Yes, we are trying to take smaller incremental steps. Once the we are done with this work we can step back and discuss/review what to do about shuffles.

@PaulSandoz Thanks a lot for the review and the CSR. I will look forward to Hotspot review and CSR progress/approval.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2353449454

From psandoz at openjdk.org  Mon Sep 16 17:08:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 17:08:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v12]
In-Reply-To: <jJtmOxc9xlDm-_nyovuF4xXeW2KAkvYcqIpC3vyx--g=.cf792925-86f5-49ff-9a22-0b5ad4d0b8d9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <jJtmOxc9xlDm-_nyovuF4xXeW2KAkvYcqIpC3vyx--g=.cf792925-86f5-49ff-9a22-0b5ad4d0b8d9@github.com>
Message-ID: <K5-6IBwdcFLZH_fsiwns7noN1J-ATlbEJ5tlNtO1ELM=.9063ee27-caab-4356-92b4-c9b706afc3e4@github.com>

On Sat, 14 Sep 2024 08:40:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update AARCH64 specific test using UNSIGNED_* comparison operators.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 573:

> 571:      * @see VectorMath#addSaturating(int, int)
> 572:      */
> 573:     public static final Associative SADD = assoc("SADD", "+", VectorSupport.VECTOR_OP_SADD, VO_NOFP);

Change from type `Associative` to `Binary` for `SADD` and `SUADD`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1761527956

From naoto at openjdk.org  Mon Sep 16 17:12:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Sep 2024 17:12:11 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ
 files [v2]
In-Reply-To: <1-KRYUYxuzPryIf5slU0YGMUzlA3D0x_z2t29RT-pxw=.040937e1-4a6d-4d89-9616-cbca7e2a2f62@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
 <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
 <1-KRYUYxuzPryIf5slU0YGMUzlA3D0x_z2t29RT-pxw=.040937e1-4a6d-4d89-9616-cbca7e2a2f62@github.com>
Message-ID: <d2tlGwa2f0gSiclw9Mj_-wVzV2kbnZFir9vazbgz4Mc=.48886a91-757a-4e50-8d2f-e247fa6ec39f@github.com>

On Sat, 14 Sep 2024 09:20:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not add all links
>
> src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 270:
> 
>> 268:         ResourceBundle fd = lr.getJavaTimeFormatData();
>> 269:         var zi = ZoneInfoFile.getZoneInfo(id);
>> 270:         if (zi == null) {
> 
> This is an added fallback, and is not related to the "%z" logic right?

Right. Since `getZoneInfo()` could return `null`, this is just for safety.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20979#discussion_r1761534541

From bpb at openjdk.org  Mon Sep 16 17:16:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Sep 2024 17:16:41 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v7]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <u9oYvV06NlJbRkb94zgnqXHFH9-dOE8LUw7qOKXWiRQ=.6b3d8fff-c90e-4501-af12-0dd39bfda948@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Address reviewer comments on FOS and RAF constructor verbiage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/f492c36a..a6c21681

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=05-06

  Stats: 37 lines in 2 files changed: 12 ins; 12 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From jlu at openjdk.org  Mon Sep 16 17:29:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Sep 2024 17:29:18 GMT
Subject: Integrated: 8339769: Incorrect error message during startup if working
 directory does not exist
In-Reply-To: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
Message-ID: <_TEg7pQs1SG6q108PTctds_zQDmmCCDcnJKz93KQTdw=.4ca76215-5be6-4f28-bd4c-2fcda6aed974@github.com>

On Thu, 12 Sep 2024 21:56:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
> 
> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
> 
> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
> 
> 
>     // Get the platform specific values
>     sprops = GetJavaProperties(env);
>     CHECK_NULL_RETURN(sprops, NULL);
> 
> 
> Testing done locally on both platforms.

This pull request has now been integrated.

Changeset: 65b9abaa
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65b9abaa29eb9fe801b650ce787d98c31770a5dc
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8339769: Incorrect error message during startup if working directory does not exist

Reviewed-by: naoto, dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20975

From jlu at openjdk.org  Mon Sep 16 17:29:15 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Sep 2024 17:29:15 GMT
Subject: RFR: 8339769: Incorrect error message during startup if working
 directory does not exist [v3]
In-Reply-To: <SPEk1zMMPaVDEmZgLc4Cu7F9p7Zwb-klxXKXvSrIhJg=.1e640932-abe0-4aa1-b7bb-f9b6a99399a4@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <SPEk1zMMPaVDEmZgLc4Cu7F9p7Zwb-klxXKXvSrIhJg=.1e640932-abe0-4aa1-b7bb-f9b6a99399a4@github.com>
Message-ID: <iTMLBy-7RdlFtD_y_QD6IyZzoRlLXAz8WO4WnNV8mE4=.58fa73da-0db6-4600-b383-f93f20a85907@github.com>

On Fri, 13 Sep 2024 16:41:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix bad spacing

Thanks for the approvals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20975#issuecomment-2353499065

From naoto at openjdk.org  Mon Sep 16 17:29:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Sep 2024 17:29:14 GMT
Subject: RFR: 8339769: Incorrect error message during startup if working
 directory does not exist [v3]
In-Reply-To: <SPEk1zMMPaVDEmZgLc4Cu7F9p7Zwb-klxXKXvSrIhJg=.1e640932-abe0-4aa1-b7bb-f9b6a99399a4@github.com>
References: <JKrmu_vBL9HxHQe9slm06LR8T-tU-GjaettJVxVs4lM=.ef38e002-d2fd-439a-af02-5390baa45934@github.com>
 <SPEk1zMMPaVDEmZgLc4Cu7F9p7Zwb-klxXKXvSrIhJg=.1e640932-abe0-4aa1-b7bb-f9b6a99399a4@github.com>
Message-ID: <3QtmlgYA7t889d7tiOCXAsKgePKAeDnQgX7Gq-5dprw=.f18d307a-dfbd-4bf5-b9e8-32375bf9e2e0@github.com>

On Fri, 13 Sep 2024 16:41:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which restores the correct exception message when the current working directory can not be found during java startup in `initPhase1`.
>> 
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Properties init: Could not determine current working directory` if the _user.dir_ system property cannot be initialized. Currently, MacOS now fails with `java.lang.InternalError: platform encoding not initialized` and Linux fails with  `java.lang.InternalError: null property: user.dir` which are both unexpected messages. 
>> 
>> In `System.c`, `Java_jdk_internal_util_SystemProps_00024Raw_platformProperties` calls `GetJavaProperties(JNIEnv *env)` which throws an internal error (with an appropriate message) for Unix platforms when the current working directory cannot be found. However, this exception is never checked and thus unexpected failures occur later. NULL should be returned after the exception is thrown, so that the initialization fails with the expected error when the return value is checked.
>> 
>> 
>>     // Get the platform specific values
>>     sprops = GetJavaProperties(env);
>>     CHECK_NULL_RETURN(sprops, NULL);
>> 
>> 
>> Testing done locally on both platforms.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix bad spacing

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20975#pullrequestreview-2307284368

From alanb at openjdk.org  Mon Sep 16 17:47:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Sep 2024 17:47:06 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v7]
In-Reply-To: <u9oYvV06NlJbRkb94zgnqXHFH9-dOE8LUw7qOKXWiRQ=.6b3d8fff-c90e-4501-af12-0dd39bfda948@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <u9oYvV06NlJbRkb94zgnqXHFH9-dOE8LUw7qOKXWiRQ=.6b3d8fff-c90e-4501-af12-0dd39bfda948@github.com>
Message-ID: <_EQ5HlA2Hy3fau38ea4dGOmgUs5weFFbtC9hrokYUk8=.e31480f9-a366-4762-bd48-ee9131b0b078@github.com>

On Mon, 16 Sep 2024 17:16:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Address reviewer comments on FOS and RAF constructor verbiage

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20878#pullrequestreview-2307326039

From henryjen at openjdk.org  Mon Sep 16 17:55:25 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 16 Sep 2024 17:55:25 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
Message-ID: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>

?nge while creating a jlink image

-------------

Commit messages:
 - 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image

Changes: https://git.openjdk.org/jdk/pull/21022/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321413
  Stats: 542 lines in 2 files changed: 286 ins; 126 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/21022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21022/head:pull/21022

PR: https://git.openjdk.org/jdk/pull/21022

From duke at openjdk.org  Mon Sep 16 18:01:49 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 16 Sep 2024 18:01:49 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v7]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <wA2w83LiO6_oBYiHju2v0GqAwgF6vsnUkRt9hGz1_Xs=.c88fd191-76c8-41e5-a439-ebdd041ab331@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with three additional commits since the last revision:

 - Update HyperbolicTests.java
   
   Remove the path to random library
 - update copyright year and remove unused random from HyperbolicTests
 - remove tanh tests in seprate file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/ca3314c5..e908eb44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=05-06

  Stats: 1640 lines in 2 files changed: 735 ins; 892 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From alanb at openjdk.org  Mon Sep 16 18:03:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Sep 2024 18:03:05 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
Message-ID: <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>

On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @link ->@linkplain

src/java.base/share/classes/java/util/zip/ZipEntry.java line 44:

> 42:  * entry comment and {@linkplain #CENHDR CEN Header size}, must not
> 43:  * exceed 65,535 bytes. If it does, {@linkplain ZipOutputStream} will
> 44:  * throw a {@linkplain ZipException} when writing the ZIP file entry.

This looks a little out of place in ZipEntry's class description, does ZOS.putNextEntry throw or is it just finish and close?

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 409:

> 407:      * A ZipException will be thrown if the combined length of the entry name,
> 408:      * the extra field data, the entry comment and {@linkplain #CENHDR CEN Header size},
> 409:      * exceeds 65,535 bytes.

Is this missing text to say that close may write as part of closing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761614191
PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761616171

From lancea at openjdk.org  Mon Sep 16 18:15:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 18:15:10 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
Message-ID: <yK42VaWF50lZF0L34YcYOqo02--yVAE-k4kp2CSTd2k=.d6f8104a-0135-4b0a-acfd-63f45f3e9a76@github.com>

On Mon, 16 Sep 2024 18:00:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update @link ->@linkplain
>
> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 409:
> 
>> 407:      * A ZipException will be thrown if the combined length of the entry name,
>> 408:      * the extra field data, the entry comment and {@linkplain #CENHDR CEN Header size},
>> 409:      * exceeds 65,535 bytes.
> 
> Is this missing text to say that close may write as part of closing?

ZipOutputStream::close() calls DeflaterOutputStream::close() will in turn will call ZipOutputStream::finish()

I could remove the above and just leave the verbiage in ZipOutputStream::finish(), I only added it to close as I didn't think it was obvious that close resulted in a call to finish.

I do not have a strong preference or do you have an alterantive suggestion?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761630685

From alanb at openjdk.org  Mon Sep 16 18:22:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Sep 2024 18:22:07 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <yK42VaWF50lZF0L34YcYOqo02--yVAE-k4kp2CSTd2k=.d6f8104a-0135-4b0a-acfd-63f45f3e9a76@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
 <yK42VaWF50lZF0L34YcYOqo02--yVAE-k4kp2CSTd2k=.d6f8104a-0135-4b0a-acfd-63f45f3e9a76@github.com>
Message-ID: <ABuRmMuFDqpgn8J5qjpOeA8AeDG3g1ZdnMvc8gKhmEE=.7c3a960d-1d00-4c63-b20e-68401215cfd9@github.com>

On Mon, 16 Sep 2024 18:12:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 409:
>> 
>>> 407:      * A ZipException will be thrown if the combined length of the entry name,
>>> 408:      * the extra field data, the entry comment and {@linkplain #CENHDR CEN Header size},
>>> 409:      * exceeds 65,535 bytes.
>> 
>> Is this missing text to say that close may write as part of closing?
>
> ZipOutputStream::close() calls DeflaterOutputStream::close() will in turn will call ZipOutputStream::finish()
> 
> I could remove the above and just leave the verbiage in ZipOutputStream::finish(), I only added it to close as I didn't think it was obvious that close resulted in a call to finish.
> 
> I do not have a strong preference or do you have an alterantive suggestion?

I think having ZOS.close say that it finishes writing the contents of the ZIP output stream and closes it, would make the API docs easier to read. If you do then no need for close to talk about the ZipException.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761641300

From duke at openjdk.org  Mon Sep 16 18:22:56 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 16 Sep 2024 18:22:56 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v8]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <kfwnOa2ig_s0iBWrvtYSqDdIf9epYzJUuLy1Gy3h8h0=.d6035ae7-b5e3-470a-89ee-d07fd2b53b05@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa 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 12 additional commits since the last revision:

 - update tanh additional tests
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into onetanh
 - Update HyperbolicTests.java
   
   Remove the path to random library
 - update copyright year and remove unused random from HyperbolicTests
 - remove tanh tests in seprate file
 - Update test/jdk/java/lang/Math/HyperbolicTests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - quad precision tanh tests
 - c1 and template generator fixes
 - update libm tanh reference test with code review suggestions
 - Add stub initialization and extra tanh tests
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7110935c...3664be15

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/e908eb44..3664be15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=06-07

  Stats: 111889 lines in 2917 files changed: 66503 ins; 28786 del; 16600 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From duke at openjdk.org  Mon Sep 16 18:22:56 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 16 Sep 2024 18:22:56 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <N08c2VRDNCMK2udQU3W5m7In_llDorc3APwMxr-u_CA=.113c4227-2360-4258-b6fc-1ea77922466d@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>
 <nyIM1XCZwZFzF_DJMu6HLT-pZWOevJqD6UzBzWqBC4Q=.ed21ec78-6e12-4a76-8d9f-73912fbcdaa5@github.com>
 <PE4PXsFykcLP3IPBsekOZMZTl92d5ZIkGpwoHBFWgH0=.43476fe0-7648-49d1-9cdd-4ef528bb5f6e@github.com>
 <y3E8zbGHmEBRIBBbrAsvDFRAjrh5PeyCQuCPqLp5Ldk=.486ff24f-5717-4f98-9a22-0035514a7e36@github.com>
 <0cm-1lCXQVJaCJbfp7evFyNvkLFxwUyfSukdy40aVxY=.7129df0b-d9a0-4a3b-b7f6-53f767b01ef6@github.com>
 <N08c2VRDNCMK2udQU3W5m7In_llDorc3APwMxr-u_CA=.113c4227-2360-4258-b6fc-1ea77922466d@github.com>
Message-ID: <wkfWSGDOU2ufhCzSoTJ7m2BcQeJ4GMIeemsFlJj2tmk=.90303b35-b175-4798-be80-bdd5a1858de8@github.com>

On Fri, 13 Sep 2024 23:10:19 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Hi Joe (@jddarcy),
>> 
>> As suggested by Sandhya (@sviswa7), I added ~750 fixed point tests for tanh in `TanhTests.java` using the quad precision tanh implementation in libquadmath library from gcc. 
>> 
>> Please let me know if this looks good.
>
> @vamsi-parasa In my thoughts the best way to do this is add the additional tests points to HyperbolicTests.java itself in the testcases array of testTanh() method. We should remove all the other changes from HyperbolicTests.java. Also no need for separate TanhTests.java file.

Hi Sandhya(@sviswa7), please see the updated code in `HyperbolicTests.java` which removes the previous random based tests with the new fixed point tests. Also removed the `TanhTests.java`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1761642227

From lancea at openjdk.org  Mon Sep 16 18:25:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 18:25:10 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
Message-ID: <8h5wZGYDFIjeBVIq2Usa-kC0ehxwf5rldp-Wp_mJUYA=.2a58013e-4794-4ce1-bbe3-6b1774399062@github.com>

On Mon, 16 Sep 2024 17:59:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update @link ->@linkplain
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 44:
> 
>> 42:  * entry comment and {@linkplain #CENHDR CEN Header size}, must not
>> 43:  * exceed 65,535 bytes. If it does, {@linkplain ZipOutputStream} will
>> 44:  * throw a {@linkplain ZipException} when writing the ZIP file entry.
> 
> This looks a little out of place in ZipEntry's class description, does ZOS.putNextEntry throw or is it just finish and close?

Short answer. finish() which calls writeCEN, will throw for the above.

 As the entry comment, is only part of the CEN, I wanted to keep the encoding in writeCEN as there is no reason to do it earlier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761646379

From joehw at openjdk.org  Mon Sep 16 18:27:07 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 16 Sep 2024 18:27:07 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ
 files [v2]
In-Reply-To: <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
 <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
Message-ID: <sKh52Eq94DV9eXtEVS74ej4GRcL2zGat49t1OtwyTgE=.767a1aa3-5346-4dc0-8d65-658497115b59@github.com>

On Fri, 13 Sep 2024 18:39:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
>> ...
>>       The main source files' time zone abbreviations now use %z,
>>       supported by zic since release 2015f and used in vanguard form
>>       since release 2022b. For example, America/Sao_Paulo now contains
>>       the zone continuation line "-3:00 Brazil %z", which is less error
>>       prone than the old "-3:00 Brazil -03/-02". This does not change
>>       the represented data: the generated TZif files are unchanged.
>>       Rearguard form still avoids %z, to support obsolescent parsers.
>> ...
>> 
>> Also fixed the logic to retrieve the linked tz name that is chaining.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not add all links

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20979#pullrequestreview-2307419548

From lancea at openjdk.org  Mon Sep 16 18:37:05 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 18:37:05 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <ABuRmMuFDqpgn8J5qjpOeA8AeDG3g1ZdnMvc8gKhmEE=.7c3a960d-1d00-4c63-b20e-68401215cfd9@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
 <yK42VaWF50lZF0L34YcYOqo02--yVAE-k4kp2CSTd2k=.d6f8104a-0135-4b0a-acfd-63f45f3e9a76@github.com>
 <ABuRmMuFDqpgn8J5qjpOeA8AeDG3g1ZdnMvc8gKhmEE=.7c3a960d-1d00-4c63-b20e-68401215cfd9@github.com>
Message-ID: <OBErB-rpvbutZ-Op3gPV_eUZikictNJVsh6Hy7vSVfg=.ff46687e-4298-4ba0-8add-b6aa7e8e8f17@github.com>

On Mon, 16 Sep 2024 18:19:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ZipOutputStream::close() calls DeflaterOutputStream::close() will in turn will call ZipOutputStream::finish()
>> 
>> I could remove the above and just leave the verbiage in ZipOutputStream::finish(), I only added it to close as I didn't think it was obvious that close resulted in a call to finish.
>> 
>> I do not have a strong preference or do you have an alterantive suggestion?
>
> I think having ZOS.close say that it finishes writing the contents of the ZIP output stream and closes it, would make the API docs easier to read. If you do then no need for close to talk about the ZipException.

Is this what you were thinking:

 

     /**
-     * Closes the ZIP output stream as well as the stream being filtered.
+     * Finishes writing the contents of the ZIP output stream. The
+     * underlying stream will also be closed as well as the stream being filtered.
      * <p>
-     * A ZipException will be thrown if the combined length of the entry name,
-     * the extra field data, the entry comment and {@linkplain #CENHDR CEN Header size},
-     * exceeds 65,535 bytes.
      * @throws    ZipException if a ZIP file error has occurred
      * @throws    IOException if an I/O error has occurred
      */

And leaving the verbiage in finish() as is?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761662664

From lancea at openjdk.org  Mon Sep 16 18:47:11 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 18:47:11 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <KZP2gxX4Y64gk5dRCTaQJxp066PsMBeUniLLEqtwLGY=.0a775758-ddb3-4e61-bd64-698da98e668f@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <NRsNgdaAXzhnFLJekkViqPUqcXdi3if8h3vzNIeVkPQ=.0e310322-168c-4416-846a-81b4a74b96a4@github.com>
 <ZPI3etSj1iahuh0oaZKWvB5vQR3yDygAg4W6Z9nSJv8=.ebca96e7-f243-40f3-b55b-dac2ecbae907@github.com>
 <KZP2gxX4Y64gk5dRCTaQJxp066PsMBeUniLLEqtwLGY=.0a775758-ddb3-4e61-bd64-698da98e668f@github.com>
Message-ID: <xQ451oPIYRvo0JtXvIJCeo6wptc-4thpjxkBf-774b8=.34bb5bda-5169-4c29-9926-0a71ce7988a9@github.com>

On Mon, 16 Sep 2024 11:59:22 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> I am not sure it is needed, but could tweak to 
>> 
>>> The combined length, after encoding, of the ......
>> 
>> thoughts?
>
>> > The combined length, after encoding, of the ......
>> 
>> thoughts?
> 
> I like it. Disambiguating but also succinct.

Set to be updated as part of the next PR push

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761677041

From psandoz at openjdk.org  Mon Sep 16 18:47:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 18:47:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
Message-ID: <NfMEKeVYMB7GCEcfNyV-I2n-XjllH1tyN0Sd5b9MVJ0=.64e81e4d-5506-4002-bc52-2cacc0e590c9@github.com>

On Mon, 16 Sep 2024 02:58:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 561:

> 559:         for (int i = 0; i < vlen; i++) {
> 560:             int index = ((int)vecPayload1[i]);
> 561:             res[i] = index >= vlen ? vecPayload3[index & (vlen - 1)] : vecPayload2[index];

This is incorrect as the index could be negative. You need to wrap in the range `[0, 2 * vlen - 1]` before the comparison and selection.

int index = ((int)vecPayload1[i]) & ((vlen << 1) - 1));
res[i] = index < vlen ? vecPayload2[index] : vecPayload3[index - vlen];

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2974:

> 2972:     final $abstractvectortype$ selectFromTemplate(Class<? extends Vector<$Boxbitstype$>> indexVecClass,
> 2973:                                                   $abstractvectortype$ v1, $abstractvectortype$ v2) {
> 2974:         int twoVectorLen = length() * 2;

We should assert that the length is a power of two.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1761663646
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1761667602

From alanb at openjdk.org  Mon Sep 16 18:50:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Sep 2024 18:50:05 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <8h5wZGYDFIjeBVIq2Usa-kC0ehxwf5rldp-Wp_mJUYA=.2a58013e-4794-4ce1-bbe3-6b1774399062@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
 <8h5wZGYDFIjeBVIq2Usa-kC0ehxwf5rldp-Wp_mJUYA=.2a58013e-4794-4ce1-bbe3-6b1774399062@github.com>
Message-ID: <6yqrwwiPLFyNimkhucwG-qCHsul-NCT8GcUtkwzvcGs=.41c96187-19a7-4479-9717-a33541ffbb29@github.com>

On Mon, 16 Sep 2024 18:22:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipEntry.java line 44:
>> 
>>> 42:  * entry comment and {@linkplain #CENHDR CEN Header size}, must not
>>> 43:  * exceed 65,535 bytes. If it does, {@linkplain ZipOutputStream} will
>>> 44:  * throw a {@linkplain ZipException} when writing the ZIP file entry.
>> 
>> This looks a little out of place in ZipEntry's class description, does ZOS.putNextEntry throw or is it just finish and close?
>
> Short answer. finish() which calls writeCEN, will throw for the above.
> 
>  As the entry comment, is only part of the CEN, I wanted to keep the encoding in writeCEN as there is no reason to do it earlier.

I looks very out of place when reading ZipEntry's class description. I think we'll have to move to the places where the exception is thrown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761684317

From lancea at openjdk.org  Mon Sep 16 18:54:08 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 16 Sep 2024 18:54:08 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <6yqrwwiPLFyNimkhucwG-qCHsul-NCT8GcUtkwzvcGs=.41c96187-19a7-4479-9717-a33541ffbb29@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <Gqz6tfYrcCvSs6QDiltD9ifMiA5p1uGoFrkT-pVgElU=.0a60c089-b63c-47c1-b2de-fade8ec4aa47@github.com>
 <8h5wZGYDFIjeBVIq2Usa-kC0ehxwf5rldp-Wp_mJUYA=.2a58013e-4794-4ce1-bbe3-6b1774399062@github.com>
 <6yqrwwiPLFyNimkhucwG-qCHsul-NCT8GcUtkwzvcGs=.41c96187-19a7-4479-9717-a33541ffbb29@github.com>
Message-ID: <fHduvx7cz1hjKhe-k9PgVj7zgE2WtoWFBHn1pr0pKsM=.3da26c0f-68eb-422f-adcb-93b9f7f93d38@github.com>

On Mon, 16 Sep 2024 18:47:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Short answer. finish() which calls writeCEN, will throw for the above.
>> 
>>  As the entry comment, is only part of the CEN, I wanted to keep the encoding in writeCEN as there is no reason to do it earlier.
>
> I looks very out of place when reading ZipEntry's class description. I think we'll have to move to the places where the exception is thrown.

So that means removing completely from ZipEntry, which is fine.  The wording is in ZipOutputStream::finish() and was in ZipOutputStream::close(), but I believe with your proposed change, we are removing it from close

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21003#discussion_r1761689672

From coffeys at openjdk.org  Mon Sep 16 18:55:10 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 16 Sep 2024 18:55:10 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ
 files [v2]
In-Reply-To: <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
 <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
Message-ID: <_Vj-K9ceZO9iAi-TK2G_o380wbe_EwFt1JS63n1FHJw=.5716eca1-5a75-49a1-88af-339690d490cd@github.com>

On Fri, 13 Sep 2024 18:39:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
>> ...
>>       The main source files' time zone abbreviations now use %z,
>>       supported by zic since release 2015f and used in vanguard form
>>       since release 2022b. For example, America/Sao_Paulo now contains
>>       the zone continuation line "-3:00 Brazil %z", which is less error
>>       prone than the old "-3:00 Brazil -03/-02". This does not change
>>       the represented data: the generated TZif files are unchanged.
>>       Rearguard form still avoids %z, to support obsolescent parsers.
>> ...
>> 
>> Also fixed the logic to retrieve the linked tz name that is chaining.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not add all links

LGTM

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20979#pullrequestreview-2307487465

From scolebourne at openjdk.org  Mon Sep 16 19:00:17 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 16 Sep 2024 19:00:17 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
Message-ID: <W5qgUkFkonBFdVp1z3euaeoaoWIE7UPLzgT_ndWUSPs=.6e8abe9a-023b-4948-8ebd-fa99e0e2946a@github.com>

On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tz files aligned with the default TzdbZoneRulesProvider list

make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308:

> 306:             if (off < tokens.length) {
> 307:                 String dayRule = tokens[off++];
> 308:                 if (dayRule.regionMatches(true, 0, "last", 0, 4)) {

This isn't correct, as per the mailing list:

> > can "last" contain uppercase letters, or
> > does it have to be exactly "last"?
> 
> In that case the name is "lastSunday", and it can be abbreviated
> "lastSu" or "Lastsu" or "LASTSUNDA" or whatever.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1761697764

From bpb at openjdk.org  Mon Sep 16 19:09:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Sep 2024 19:09:03 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v8]
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <3HwQ0DoRX75LPI2nDwb4kYrs6XUCqwo6TovKWENRrIg=.bba9d8ec-14a6-4d89-be86-0dc1678975d1@github.com>

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8339574: Add symbolic link verbiage to File.deleteOnExit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20878/files
  - new: https://git.openjdk.org/jdk/pull/20878/files/a6c21681..ea4e5575

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20878&range=06-07

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20878/head:pull/20878

PR: https://git.openjdk.org/jdk/pull/20878

From naoto at openjdk.org  Mon Sep 16 19:33:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Sep 2024 19:33:09 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <W5qgUkFkonBFdVp1z3euaeoaoWIE7UPLzgT_ndWUSPs=.6e8abe9a-023b-4948-8ebd-fa99e0e2946a@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
 <W5qgUkFkonBFdVp1z3euaeoaoWIE7UPLzgT_ndWUSPs=.6e8abe9a-023b-4948-8ebd-fa99e0e2946a@github.com>
Message-ID: <PUqKEvGlV6J2soN4aKM4hvSiZkzmWKqCibXzuvaSh_M=.a3ba86fb-d407-4bba-8b3a-1c16fd34bfee@github.com>

On Mon, 16 Sep 2024 18:57:42 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tz files aligned with the default TzdbZoneRulesProvider list
>
> make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308:
> 
>> 306:             if (off < tokens.length) {
>> 307:                 String dayRule = tokens[off++];
>> 308:                 if (dayRule.regionMatches(true, 0, "last", 0, 4)) {
> 
> This isn't correct, as per the mailing list:
> 
>> > can "last" contain uppercase letters, or
>> > does it have to be exactly "last"?
>> 
>> In that case the name is "lastSunday", and it can be abbreviated
>> "lastSu" or "Lastsu" or "LASTSUNDA" or whatever.

Why is it not? IIUC, abbreviation should be unambiguous, so "last" part is always case-insensitive 4 character length.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1761768765

From scolebourne at openjdk.org  Mon Sep 16 19:39:09 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 16 Sep 2024 19:39:09 GMT
Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in
 tzdata files [v2]
In-Reply-To: <PUqKEvGlV6J2soN4aKM4hvSiZkzmWKqCibXzuvaSh_M=.a3ba86fb-d407-4bba-8b3a-1c16fd34bfee@github.com>
References: <P8bpXburMtKPhw_MDM3Fh8qk7zeVZhyGLwvezTWh7zs=.6990f324-e3b4-464a-bf73-82ec1b8c6863@github.com>
 <AobLtmAgH0Aq1BBWFkyTPae90l2X4HM78TYtEEeyZbo=.2102e295-cfaf-4e4d-bbf2-f36e17bad680@github.com>
 <W5qgUkFkonBFdVp1z3euaeoaoWIE7UPLzgT_ndWUSPs=.6e8abe9a-023b-4948-8ebd-fa99e0e2946a@github.com>
 <PUqKEvGlV6J2soN4aKM4hvSiZkzmWKqCibXzuvaSh_M=.a3ba86fb-d407-4bba-8b3a-1c16fd34bfee@github.com>
Message-ID: <t4p_8QKqy1zrREdeB_460x0xXpnuIjY4v0mj6-eWdIE=.20202525-17dd-4362-a9f1-6d3b5a3f61a9@github.com>

On Mon, 16 Sep 2024 19:30:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308:
>> 
>>> 306:             if (off < tokens.length) {
>>> 307:                 String dayRule = tokens[off++];
>>> 308:                 if (dayRule.regionMatches(true, 0, "last", 0, 4)) {
>> 
>> This isn't correct, as per the mailing list:
>> 
>>> > can "last" contain uppercase letters, or
>>> > does it have to be exactly "last"?
>>> 
>>> In that case the name is "lastSunday", and it can be abbreviated
>>> "lastSu" or "Lastsu" or "LASTSUNDA" or whatever.
>
> Why is it not? IIUC, abbreviation should be unambiguous, so "last" part is always case-insensitive 4 character length.

Sorry, I assumed this regionMatches was the same as the others. "last" is always "last" and never abbreviated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1761774912

From naoto at openjdk.org  Mon Sep 16 20:06:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Sep 2024 20:06:08 GMT
Subject: RFR: 8340073: Support "%z" time zone abbreviation format in TZ
 files [v2]
In-Reply-To: <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
 <pwqgtepkpoFkrsxkgRrlRwmpsOj2J0oAmKlU5MR4tg8=.be8e58d9-4a97-4b15-a920-1c6b36f15f2c@github.com>
Message-ID: <9e29zmdNhrPoNW8uMwsMcNV9_fcq0DWpnsOTqjDKtjU=.952cc90f-2092-407b-8eb0-42bbbb447993@github.com>

On Fri, 13 Sep 2024 18:39:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
>> ...
>>       The main source files' time zone abbreviations now use %z,
>>       supported by zic since release 2015f and used in vanguard form
>>       since release 2022b. For example, America/Sao_Paulo now contains
>>       the zone continuation line "-3:00 Brazil %z", which is less error
>>       prone than the old "-3:00 Brazil -03/-02". This does not change
>>       the represented data: the generated TZif files are unchanged.
>>       Rearguard form still avoids %z, to support obsolescent parsers.
>> ...
>> 
>> Also fixed the logic to retrieve the linked tz name that is chaining.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not add all links

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20979#issuecomment-2353804321

From naoto at openjdk.org  Mon Sep 16 20:06:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Sep 2024 20:06:09 GMT
Subject: Integrated: 8340073: Support "%z" time zone abbreviation format in TZ
 files
In-Reply-To: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
References: <5_SDFx4CF3W9ggJEzt308KIods2xBg_CI_Gp3W44KUA=.cc844c40-a8c5-4e2a-86a3-4b034677559f@github.com>
Message-ID: <t2cpwNspfavKfdaBlltbqNyF6p4m4fUroYkNPdSLW0A=.74519202-d2b4-4b4e-a0a4-17e42b755a2e@github.com>

On Thu, 12 Sep 2024 23:03:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Yet another preparation for upgrading the time zone data to 2024b, which introduced a new abbreviation format "%z". The update includes:
> ...
>       The main source files' time zone abbreviations now use %z,
>       supported by zic since release 2015f and used in vanguard form
>       since release 2022b. For example, America/Sao_Paulo now contains
>       the zone continuation line "-3:00 Brazil %z", which is less error
>       prone than the old "-3:00 Brazil -03/-02". This does not change
>       the represented data: the generated TZif files are unchanged.
>       Rearguard form still avoids %z, to support obsolescent parsers.
> ...
> 
> Also fixed the logic to retrieve the linked tz name that is chaining.

This pull request has now been integrated.

Changeset: 418bb42b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/418bb42b95b177f5f31f756054d0dd83740c6686
Stats:     19 lines in 2 files changed: 10 ins; 2 del; 7 mod

8340073: Support "%z" time zone abbreviation format in TZ files

Reviewed-by: jlu, joehw, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/20979

From psandoz at openjdk.org  Mon Sep 16 21:21:11 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 21:21:11 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
Message-ID: <aby5giDrLlJPPoRuYDw-r2dPYe5oqmPsSvTqyZJFz-A=.f7a4d939-7dc6-49fa-a4d2-5e7f1256c1bf@github.com>

On Mon, 16 Sep 2024 02:58:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2970:

> 2968: 
> 2969: 
> 2970:     /*package-private*/

I think we can simplify with:

    /*package-private*/
    @ForceInline
    final $abstractvectortype$ selectFromTemplate(Class<? extends Vector<$Boxbitstype$>> indexVecClass,
                                                  $abstractvectortype$ v1, $abstractvectortype$ v2) {
        int twoVectorLenMask = (length() << 1) - 1;
#if[FP]
        Vector<$Boxbitstype$> wrapped_indexes = this.convert(VectorOperators.{#if[intOrFloat]?F2I:D2L}, 0)
                                                   .lanewise(VectorOperators.AND, twoVectorLenMask);
        return VectorSupport.selectFromTwoVectorOp(getClass(), indexVecClass , $type$.class, $bitstype$.class,
                                                   length(), wrapped_indexes, v1, v2,
                                                   (vec1, vec2, vec3) -> selectFromTwoVectorHelper(vec1, vec2, vec3)
        );
#else[FP]
        $abstractvectortype$ wrapped_indexes = this.lanewise(VectorOperators.AND, twoVectorLenMask);
        return VectorSupport.selectFromTwoVectorOp(getClass(), indexVecClass, $type$.class, $type$.class,
                                                   length(), wrapped_indexes, v1, v2,
                                                   (vec1, vec2, vec3) -> selectFromTwoVectorHelper(vec1, vec2, vec3)
        );
#end[FP]
    }

(Note that's without the assert - see separate comment).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1761977004

From duke at openjdk.org  Mon Sep 16 22:03:09 2024
From: duke at openjdk.org (duke)
Date: Mon, 16 Sep 2024 22:03:09 GMT
Subject: Withdrawn: 8316882: Do not close ZipFileSystem on interrupt
In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
Message-ID: <HUXhgZooeUMq0K_CCp-U9vdqXNLzEUYtLxCi6g-oxg4=.25d5bbb8-e4d3-4eb0-aab4-21f136a74cb6@github.com>

On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n <duke at openjdk.org> wrote:

> Hi,
> 
> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example.
> 
> There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2]
> 
> [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html
> [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20274

From duke at openjdk.org  Mon Sep 16 23:01:08 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 16 Sep 2024 23:01:08 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v9]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <1TAqO7DOjjkXpbdTmsDbByq9kxPnaX1Ev57KnKWakjQ=.e0c25c34-fc49-445a-8cd2-7dd0fae64e80@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa 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 branch 'master' of https://git.openjdk.java.net/jdk into onetanh
 - update tanh additional tests
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into onetanh
 - Update HyperbolicTests.java
   
   Remove the path to random library
 - update copyright year and remove unused random from HyperbolicTests
 - remove tanh tests in seprate file
 - Update test/jdk/java/lang/Math/HyperbolicTests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - quad precision tanh tests
 - c1 and template generator fixes
 - update libm tanh reference test with code review suggestions
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e48dd57e...b438555e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/3664be15..b438555e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=07-08

  Stats: 344 lines in 9 files changed: 329 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From bpb at openjdk.org  Mon Sep 16 23:23:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Sep 2024 23:23:11 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v6]
In-Reply-To: <9Myxrbgw0SuFOLzWZeAuK9I7lmEN4488gDr3lmyFBtc=.ae149a97-fa20-4152-ab2a-7bbe65f10843@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
 <9Myxrbgw0SuFOLzWZeAuK9I7lmEN4488gDr3lmyFBtc=.ae149a97-fa20-4152-ab2a-7bbe65f10843@github.com>
Message-ID: <qxjNCyHSu36ifb02gppMRx9bJLbuYdEx5E7g2d55-oo=.c5e6a165-fbda-4b51-8d2a-81e2685c548f@github.com>

On Sat, 14 Sep 2024 07:03:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8339574: Move symbolic link verbiage from class to constructor doc in FIS/FOS/RAF
>
> src/java.base/share/classes/java/io/FileOutputStream.java line 103:
> 
>> 101:      * are automatically redirected to the <i>target</i> of the link.
>> 102:      * If the file or link target exists, then it will be truncated.
>> 103:      * A new {@code FileDescriptor} object is
> 
> This wording gives the impression that a link can be truncated :-)
> 
> I think the second sentence needs to say that it truncates an existing file, otherwise creates a new file. Then follow with the sentence on sym link behavior.

Fixed in a6c2168.

> src/java.base/share/classes/java/io/RandomAccessFile.java line 108:
> 
>> 106:      * are automatically redirected to the <i>target</i> of the link.
>> 107:      * If the access mode specifies writing and the file or link target exists,
>> 108:      * then it will be truncated.
> 
> I think you've copied the text from FOS but it doesn't work here as RAF doesn't truncate.
> 
> For "r" mode, it opens an existing file. For the "rw" and variants, it opens an existing file, or creates a new file if it doesn't exist.

Fixed in a6c2168.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1762073357
PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1762073459

From bpb at openjdk.org  Mon Sep 16 23:32:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Sep 2024 23:32:05 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v6]
In-Reply-To: <cxr64BoreKGvsqr_5v4bLI1Yj8se3IfNP_uLmjCj4rw=.65d2bcf7-11b3-4269-852a-4eb130b6568e@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <oK-PiyanREF_3grw1COqaiOaWdDW3YgPHxfI7M6av5k=.b2fd7825-74e3-496e-827d-0a5fe1b0b5aa@github.com>
 <cxr64BoreKGvsqr_5v4bLI1Yj8se3IfNP_uLmjCj4rw=.65d2bcf7-11b3-4269-852a-4eb130b6568e@github.com>
Message-ID: <Ar_J7g0ukUo3IBjHyGqnxl8Okb0TpMB32dUZUsW81ms=.3a0167c7-02a4-4923-ad27-56ceb5ca0d27@github.com>

On Sat, 14 Sep 2024 06:47:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8339574: Move symbolic link verbiage from class to constructor doc in FIS/FOS/RAF
>
> src/java.base/share/classes/java/io/FileInputStream.java line 90:
> 
>> 88:      * in the file system.  {@linkplain java.nio.file##links Symbolic links}
>> 89:      * are automatically redirected to the <i>target</i> of the link.
>> 90:      * A new {@code FileDescriptor}
> 
> In passing (and not for this PR) is that we should probably change the first sentence to say that it opens an existing file and drop the use of "connection".

Tracked by [JDK-8340229](https://bugs.openjdk.org/browse/JDK-8340229).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1762078989

From duke at openjdk.org  Tue Sep 17 00:41:20 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 17 Sep 2024 00:41:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v10]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <2GF3hOTuSrN9ejN_aaNWV6g5zfBdVJ93kiPjIiPUKQE=.c61b7a6c-edd9-4edd-b866-6d4969591c8a@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add call to the additional tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/b438555e..1ee4c1fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=08-09

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From jpai at openjdk.org  Tue Sep 17 00:59:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 00:59:16 GMT
Subject: RFR: 8340176: Replace usage of -noclassgc with -Xnoclassgc in
 test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
In-Reply-To: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
References: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
Message-ID: <zxQLUrCq79ZUaI_tdITTSXN_LpyrHFMpnBm2aYwGZMs=.42031f10-cbcc-45b6-a63c-fa21793494a7@github.com>

On Mon, 16 Sep 2024 09:21:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usage of `-noclassgc` with `-Xnoclassgc` option when launching the test?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340176, the `-noclassgc` is an undocumented option of the `java` launcher, which it converts to `-Xnoclassgc` before passing it to the JVM. Instead of that option, the documented `-Xnoclassgc` should be used.
> 
> No new test has been introduced and the modified test continues to pass after this change.

Thank you Kevin and Leonid for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21012#issuecomment-2354283759

From jpai at openjdk.org  Tue Sep 17 00:59:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 00:59:17 GMT
Subject: Integrated: 8340176: Replace usage of -noclassgc with -Xnoclassgc in
 test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java
In-Reply-To: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
References: <8Ce_lbltNE6CvkmqOEs_C6QymVv78oKAD87AaHEleQw=.5070ffaf-6f0e-44d8-83e0-716af1bf7180@github.com>
Message-ID: <LjYMu11C7QBAG1NLu4EwXmTQpMxpEfh19YdVZ0oW65s=.06dc363d-1cf2-40ca-aecc-eeedc73a30e8@github.com>

On Mon, 16 Sep 2024 09:21:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usage of `-noclassgc` with `-Xnoclassgc` option when launching the test?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340176, the `-noclassgc` is an undocumented option of the `java` launcher, which it converts to `-Xnoclassgc` before passing it to the JVM. Instead of that option, the documented `-Xnoclassgc` should be used.
> 
> No new test has been introduced and the modified test continues to pass after this change.

This pull request has now been integrated.

Changeset: 3e03e667
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e03e6673acfea543d0dbbc64b7a4f52e3292c2b
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8340176: Replace usage of -noclassgc with -Xnoclassgc in test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java

Reviewed-by: kevinw, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/21012

From liach at openjdk.org  Tue Sep 17 02:04:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 02:04:51 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Fix build
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Buggy 2nd attempt - crashes hotspot
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - More conflicts
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Another bug in benchmark
 - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

-------------

Changes: https://git.openjdk.org/jdk/pull/20667/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20667&range=02
  Stats: 653 lines in 7 files changed: 558 ins; 42 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/20667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20667/head:pull/20667

PR: https://git.openjdk.org/jdk/pull/20667

From duke at openjdk.org  Tue Sep 17 02:04:51 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 17 Sep 2024 02:04:51 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <y1JJyxlL01CGHFw_vbFq0lzN2uFH_VCpfPG_grdXcNA=.14280ac9-bdff-4221-a35f-3a1f6ca91463@github.com>

On Tue, 17 Sep 2024 02:01:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 559:

> 557:     public static final class ClassEntryImpl extends AbstractNamedEntry implements ClassEntry {
> 558: 
> 559:         public @Stable ClassDesc sym;

As?[GH?20957] has?now been?merged, this?can be?made to?use the?`Utf8Entry?.typeSym`?field, which would also speed up [`ConstantPoolBuilder?::classEntry?(Utf8Entry)`].

[GH?20957]: https://github.com/openjdk/jdk/pull/20957
[`ConstantPoolBuilder?::classEntry?(Utf8Entry)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#classEntry(java.lang.classfile.constantpool.Utf8Entry)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1760275110

From liach at openjdk.org  Tue Sep 17 02:04:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 02:04:51 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <y1JJyxlL01CGHFw_vbFq0lzN2uFH_VCpfPG_grdXcNA=.14280ac9-bdff-4221-a35f-3a1f6ca91463@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
 <y1JJyxlL01CGHFw_vbFq0lzN2uFH_VCpfPG_grdXcNA=.14280ac9-bdff-4221-a35f-3a1f6ca91463@github.com>
Message-ID: <JGWj0haT5SQIjW0_tY6FHW4TOb2tfYMln7BMZlKrD4Q=.3785f6ea-e6db-4d48-b440-0ff56d29fc3f@github.com>

On Sun, 15 Sep 2024 19:08:00 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Fix build
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - Buggy 2nd attempt - crashes hotspot
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - More conflicts
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - Another bug in benchmark
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 559:
> 
>> 557:     public static final class ClassEntryImpl extends AbstractNamedEntry implements ClassEntry {
>> 558: 
>> 559:         public @Stable ClassDesc sym;
> 
> As?[GH?20957] has?now been?merged, this?can be?made to?use the?`Utf8Entry?.typeSym`?field, which would also speed up [`ConstantPoolBuilder?::classEntry?(Utf8Entry)`].
> 
> [GH?20957]: https://github.com/openjdk/jdk/pull/20957
> [`ConstantPoolBuilder?::classEntry?(Utf8Entry)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/constantpool/ConstantPoolBuilder.html#classEntry(java.lang.classfile.constantpool.Utf8Entry)

I prefer not to use that field for internal name utf8 entries; that is reserved for descriptor matches, so I reuse only for arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1760363776

From liach at openjdk.org  Tue Sep 17 02:04:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 02:04:52 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <vS3YGpvG6rGt4E9J2IszN42bOcBHstdsrm8EYltWAQE=.64c3b70c-4b2d-469a-a336-117fcca343fe@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <WSNFEvaB6MBD-WwCaz3jCX5T7RtL_P2Cbyj0t20nxmw=.ccf7face-e4d7-4f59-a593-b2e7bddab2f7@github.com>
 <vS3YGpvG6rGt4E9J2IszN42bOcBHstdsrm8EYltWAQE=.64c3b70c-4b2d-469a-a336-117fcca343fe@github.com>
Message-ID: <UF3u0URpLrleBQpKktS3zUmkq4AUUjpC-LMXQGUtktk=.9b7098cd-a0de-4368-8807-3e296059af5b@github.com>

On Thu, 22 Aug 2024 13:45:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Improve benchmark as suggested
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>>  - Fix microbenchmark
>>  - Improve jmh
>>  - 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
>
> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 372:
> 
>> 370:      * }
>> 371:      * }
>> 372:      * This is converted to explicit initialization to avoid bootstrap overhead.
> 
> Have you measured this to be true and useful? Static array initializers are bulky at a bytecode level so sometimes just generating on the fly carries insignicant overhead. Then the `UtilTest` assertion test wouldn't really be needed.

I measured in bytestacks and the clinit instructions reduced by about 2/3

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1760046569

From redestad at openjdk.org  Tue Sep 17 02:04:52 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Sep 2024 02:04:52 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <UF3u0URpLrleBQpKktS3zUmkq4AUUjpC-LMXQGUtktk=.9b7098cd-a0de-4368-8807-3e296059af5b@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <WSNFEvaB6MBD-WwCaz3jCX5T7RtL_P2Cbyj0t20nxmw=.ccf7face-e4d7-4f59-a593-b2e7bddab2f7@github.com>
 <vS3YGpvG6rGt4E9J2IszN42bOcBHstdsrm8EYltWAQE=.64c3b70c-4b2d-469a-a336-117fcca343fe@github.com>
 <UF3u0URpLrleBQpKktS3zUmkq4AUUjpC-LMXQGUtktk=.9b7098cd-a0de-4368-8807-3e296059af5b@github.com>
Message-ID: <YlkCCHtpzFl_5bWmdOKhTZeCKBX3dVAhfOJ97tquAv4=.5de0b836-8000-4d2e-8f51-8f60e3212c31@github.com>

On Sun, 15 Sep 2024 13:22:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 372:
>> 
>>> 370:      * }
>>> 371:      * }
>>> 372:      * This is converted to explicit initialization to avoid bootstrap overhead.
>> 
>> Have you measured this to be true and useful? Static array initializers are bulky at a bytecode level so sometimes just generating on the fly carries insignicant overhead. Then the `UtilTest` assertion test wouldn't really be needed.
>
> I measured in bytestacks and the clinit instructions reduced by about 2/3

Yes, you have to pick and evaluate between two trade-offs here: a compact routine to compute the array, or a larger initializer which does less compute. Number of instructions executed in the interpreter is a diagnostic tool since if often hides costs that come from having to store, read, parse and manage bytecode - sometimes twice if this hits the default CDS archive. There's no definite answer, but generally the trend is towards compute getting cheaper and IO/memory getting (relatively) more expensive. So picking a larger representation to avoid some one-off compute might be the wrong trade-off.

(Note that this particular instance is probably negligible either way, I just don't want bytestacks instrumentation to put us down a path where we might ultimately end up worse off. Diagnostics needs to be verified with realistic wall clock measurements. When uncertain: go for simplicity.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1761723308

From liach at openjdk.org  Tue Sep 17 02:12:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 02:12:07 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <gue0yjts3VKDCTwLjyrN_tHuVwxodc2k8TeykhSsQiQ=.d74f8f41-e6d7-4631-8072-04ff7861c040@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Marking this as RFR; benchmarks against baseline 996790c70f902d7840d0649a6b0867bed47c6537 shows this is a net startup improvement, though the effects of this patch becomes more minuscule in larger workloads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2354364933

From darcy at openjdk.org  Tue Sep 17 02:23:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Sep 2024 02:23:09 GMT
Subject: RFR: 8339934: Simplify Math.scalb(double) method [v3]
In-Reply-To: <Aai36Xvx_vGYURofVEYLGtbdIFFXXxTs_pcDHFarD8M=.d070989f-c43b-4253-8bc5-62786e11eeec@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
 <Aai36Xvx_vGYURofVEYLGtbdIFFXXxTs_pcDHFarD8M=.d070989f-c43b-4253-8bc5-62786e11eeec@github.com>
Message-ID: <DI4gFGFHF6Es2fvEVUBCmvKmdolp53AhP7tMvPiXgoY=.27fe64c6-8615-48ba-bda3-81cc03872a16@github.com>

On Fri, 13 Sep 2024 19:33:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> `Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce primPowerOfTwoD and make use of it.

Moving to Approved.

src/java.base/share/classes/java/lang/Math.java line 3317:

> 3315:      */
> 3316:     public static double scalb(double d, int scaleFactor) {
> 3317:         /*

FWIW, I wrote this code a long time ago prior to OpenJDK. IIRC, some of the complications of this method may have been due to wanted to avoid declaring the method `strictfp` back when  `strictfp` vs default-FP semantics were an issue.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20948#pullrequestreview-2308128327
PR Review Comment: https://git.openjdk.org/jdk/pull/20948#discussion_r1762185901

From liach at openjdk.org  Tue Sep 17 02:41:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 02:41:14 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <xS6wk4MEQB0UUwvlEt0t0Y3v31CE-K10S6xX99THDho=.52b4a98e-897e-4df8-9c7e-0c255e915027@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Current benchmark numbers:
Baseline:

Benchmark                                           Mode  Cnt     Score     Error   Units
ConstantPoolBuildingClassEntry.identicalLookup     thrpt    5   649.643 ??   5.226  ops/ms
ConstantPoolBuildingClassEntry.internalNameLookup  thrpt    5  2389.365 ?? 382.997  ops/ms
ConstantPoolBuildingClassEntry.nonIdenticalLookup  thrpt    5   650.280 ??   3.360  ops/ms
ConstantPoolBuildingClassEntry.oldStyleLookup      thrpt    5   695.891 ??  10.246  ops/ms

Patch:

Benchmark                                           Mode  Cnt     Score     Error   Units
ConstantPoolBuildingClassEntry.identicalLookup     thrpt    5  2394.541 ?? 148.267  ops/ms  268.59%
ConstantPoolBuildingClassEntry.internalNameLookup  thrpt    5  1506.351 ??  21.757  ops/ms  -36.96%
ConstantPoolBuildingClassEntry.nonIdenticalLookup  thrpt    5  1908.198 ??  31.008  ops/ms  193.44%
ConstantPoolBuildingClassEntry.oldStyleLookup      thrpt    5   545.962 ??  10.603  ops/ms  -21.54%


In short, this patch is based on the assumption that ClassEntry lookup via `ClassDesc` is way more prevalent than that via a `Utf8Entry`; this is true for JDK and we would recommend all ClassFile API users to follow suit of using pre-validated symbols.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2354390268

From matias.koivikko at gmail.com  Tue Sep 10 18:15:43 2024
From: matias.koivikko at gmail.com (Matias Koivikko)
Date: Tue, 10 Sep 2024 21:15:43 +0300
Subject: Where to ask about a potential bug/oversight with hidden classes
In-Reply-To: <SJ2PR10MB76694E4E2EEC44E23593D257A29A2@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CADxF0cAC9p-73xfuxC=o6ngWYOrheDBQ+mLQsxKHTRgdKwyzPw@mail.gmail.com>
 <SJ2PR10MB76694E4E2EEC44E23593D257A29A2@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CADxF0cB4U5ze-nMpkO24PEsQqS0QheSGZ_eC=kWf8UJX=uPU0g@mail.gmail.com>

Thanks for the explanation, Chen.

I was confused by the javadoc on defineClass, as it states that references
would also be redirected during verification. I now see that class loads
during verification are irrelevant here. I was also unaware that the
receiver of field and method references were directly referring to
thisClass (mostly
due to never manually reading the constant pool and just relying
on disassemblers to combine the entries) which made me believe they were
replaced differently.

I'll probably move my setup over to using custom classloaders, as I will
need to be able to use lambdas. I don't think I can do any bytecode
patching here as I can't get the runtime name before the jvm has already
loaded the class (and I'm already generating it with ASM so I have full
control over the bytecode). Being able to do more with indy in hidden
classes would be nice, but I will for the foreseeable future be stuck on
java 21, so any new progress won't be affecting me anyway.

I now see that there was no bug or oversight and that I simply
misunderstood documentation and behaviour.

Thanks for your time, Matias

On Tue, Sep 10, 2024 at 4:47?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Matias,
> Since MethodHandles is a library API, I think we can discuss about this on
> core-libs list.
>
> About the self-reference replacement: as the spec says, it only happens to
> the thisClass Class entry in the hidden class. That means if the class is
> referenced in a method (such as a method's parameter in your class) or
> field (such as a field's type in your class) descriptor, all of which do
> not go through Class entries, the reference is kept as-is. So the lack of
> substitution for NameAndType is working as intended.
>
> Currently, LambdaMetafactory only has limited support for static methods
> in hidden classes, which was actually not available in release 22 and only
> added in release 23 development as there's a need from project Babylon.
> This is not part of LMF's specification and we might adjust this behavior
> at any time.
>
> For your purpose, you might have to bytecode process the class and patch
> references manually, or look into using non-hidden classes in custom class
> loaders instead.
>
> Regards,
> Chen
> ------------------------------
> *From:* discuss <discuss-retn at openjdk.org> on behalf of Matias Koivikko <
> matias.koivikko at gmail.com>
> *Sent:* Tuesday, September 10, 2024 7:35 AM
> *To:* discuss at openjdk.org <discuss at openjdk.org>
> *Subject:* Where to ask about a potential bug/oversight with hidden
> classes
>
> Hi everyone,
>
> I've been working on a project where I compile custom code to class files
> and load them using MethodHandles.Lookup#defineHiddenClass into the jvm.
> This seems like the correct method to me as my classes don't need to be
> referenced from the outside beyond reflectively calling a single method and
> they should ideally unload soon after unless they stored references
> somewhere.
>
> As for the bug, it involves lambdas that capture this and a
> ClassNotFoundException being thrown for the hidden class. As far as I
> understand it, the hidden class gets a randomized name at runtime and all
> references to itself within the class file should be replaced. It seems
> like this process doesn't work properly for the main NameAndType of an
> invokedynamic instruction. This would then cause a runtime crash whenever
> capturing lambdas among other uses of indy are used.
>
> Does anyone have any ideas on what I could have done wrong or where I
> should take this question further? I assume there's some more appropriate
> mailing list to discuss this issue in.
>
> Regards, Matias
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240910/c1910b15/attachment.htm>

From liach at openjdk.org  Tue Sep 17 03:29:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 03:29:15 GMT
Subject: RFR: 8340132: Remove internal CpException for reading malformed utf8
Message-ID: <4b9JSdqSCVew2frracl6hRTFgNkhsddNM-HspAaKnYI=.362ac9e2-5453-4a65-87c8-6ad1c0d77a53@github.com>

Remove an internal exception for invalid utf8 entry format; it should have been an IllegalArgumentException but was an arbitrary subtype of RuntimeException. Converted to throw ConstantPoolException, and consolidated into a single method to reduce code size.

-------------

Commit messages:
 - 8340132: Remove internal CpException for reading malformed utf8

Changes: https://git.openjdk.org/jdk/pull/21027/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21027&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340132
  Stats: 17 lines in 1 file changed: 4 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21027/head:pull/21027

PR: https://git.openjdk.org/jdk/pull/21027

From swen at openjdk.org  Tue Sep 17 03:29:30 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 17 Sep 2024 03:29:30 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
Message-ID: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>

Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF

-------------

Commit messages:
 - suggestion from @liach
 - optimize for ascii
 - only allocate the char array if we have non-ascii
 - optimize DataOutputStream::readUTF

Changes: https://git.openjdk.org/jdk/pull/20903/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20903&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340232
  Stats: 42 lines in 1 file changed: 28 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20903.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20903/head:pull/20903

PR: https://git.openjdk.org/jdk/pull/20903

From liach at openjdk.org  Tue Sep 17 03:29:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 03:29:31 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
Message-ID: <DJVUl2btPfuCt-HWiWA9Anumx_y0J9HR-W1QtdoIM9M=.4ccefc4d-6110-4401-bcb2-ab54374d2773@github.com>

On Sun, 8 Sep 2024 07:52:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF

Thanks for the logical cleanup. I will find another io reviewer too.

Another comment: we currently eagerly allocate a char array, but now we can choose to only allocate the char array if we have non-ascii.

src/java.base/share/classes/java/io/DataInputStream.java line 590:

> 588:         if (bytearr == null) {
> 589:             bytearr = new byte[utflen];
> 590:             allocate = true;

Can we rename this boolean to `trusted` and set it to `false` when we assign it back to `dis.bytearr`? Even though that assignment will be redundant, calling it `trusted` is helpful to avoid causing security problems if we reorganize this code in the future.

src/java.base/share/classes/java/io/DataInputStream.java line 609:

> 607:         }
> 608:         if (allocate && in instanceof DataInputStream dis) {
> 609:             dis.bytearr = bytearr;

Continuing last comment: after rename to `trusted`, add something like `trusted = false` here.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20903#pullrequestreview-2308109688
PR Comment: https://git.openjdk.org/jdk/pull/20903#issuecomment-2336657443
PR Review Comment: https://git.openjdk.org/jdk/pull/20903#discussion_r1761126286
PR Review Comment: https://git.openjdk.org/jdk/pull/20903#discussion_r1761127156

From swen at openjdk.org  Tue Sep 17 03:29:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 17 Sep 2024 03:29:31 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
Message-ID: <ZILsYJ1ywAme9y5Gl_tSVPcq4g3BYKjq70mwyLmyacc=.de56cbe3-ed02-43d9-9e94-677469d3b188@github.com>

On Sun, 8 Sep 2024 07:52:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF

In the readUTFAscii scenario, the performance is significantly improved, but in the readUTFSmall scenario, the performance is regressed.

Here are the performance numbers on the MacBook M1 Pro:

## Script


# baseline
git checkout fbe2629303bcee5855673b7e37d8c49f19dc9849
make test TEST="micro:java.io.DataInputStreamTest.readUTF"

# current
git checkout 5c4bd6db977ca8729e078d26cb7ca284ab42203c
make test TEST="micro:java.io.DataInputStreamTest.readUTF"



## Performance Numbers


-# baseline
-Benchmark                              Mode  Cnt  Score   Error  Units
-DataInputStreamTest.readUTFAsciiLarge  avgt   20  1.401 ? 0.005  us/op
-DataInputStreamTest.readUTFAsciiMixed  avgt   20  1.337 ? 0.092  us/op
-DataInputStreamTest.readUTFAsciiSmall  avgt   20  0.872 ? 0.004  us/op
-DataInputStreamTest.readUTFLarge       avgt   20  2.178 ? 0.050  us/op
-DataInputStreamTest.readUTFMixed       avgt   20  1.700 ? 0.109  us/op
-DataInputStreamTest.readUTFSmall       avgt   20  0.879 ? 0.012  us/op

+# current
+Benchmark                              Mode  Cnt  Score   Error  Units
+DataInputStreamTest.readUTFAsciiLarge  avgt   20  0.833 ? 0.004  us/op
+DataInputStreamTest.readUTFAsciiMixed  avgt   20  0.804 ? 0.001  us/op
+DataInputStreamTest.readUTFAsciiSmall  avgt   20  0.828 ? 0.005  us/op
+DataInputStreamTest.readUTFLarge       avgt   20  2.053 ? 0.063  us/op
+DataInputStreamTest.readUTFMixed       avgt   20  1.675 ? 0.056  us/op
+DataInputStreamTest.readUTFSmall       avgt   20  1.834 ? 0.026  us/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| DataInputStreamTest.readUTFAsciiLarge | 1.401 | 0.833 | 68.19% |
| DataInputStreamTest.readUTFAsciiMixed | 1.337 | 0.804 | 66.29% |
| DataInputStreamTest.readUTFAsciiSmall | 0.872 | 0.828 | 5.31% |
| DataInputStreamTest.readUTFLarge | 2.178 | 2.053 | 6.09% |
| DataInputStreamTest.readUTFMixed | 1.700 | 1.675 | 1.49% |
| DataInputStreamTest.readUTFSmall | 0.879 | 1.834 | -52.07% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20903#issuecomment-2347702045

From swen at openjdk.org  Tue Sep 17 03:29:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 17 Sep 2024 03:29:31 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <DJVUl2btPfuCt-HWiWA9Anumx_y0J9HR-W1QtdoIM9M=.4ccefc4d-6110-4401-bcb2-ab54374d2773@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
 <DJVUl2btPfuCt-HWiWA9Anumx_y0J9HR-W1QtdoIM9M=.4ccefc4d-6110-4401-bcb2-ab54374d2773@github.com>
Message-ID: <bnc0FJRHGBQFTiy7-YbYx4cWVoXjndKW9N8sXUVDvhk=.ef5cae10-fe83-4e02-9245-d1d8ade23030@github.com>

On Mon, 16 Sep 2024 13:15:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF
>
> src/java.base/share/classes/java/io/DataInputStream.java line 590:
> 
>> 588:         if (bytearr == null) {
>> 589:             bytearr = new byte[utflen];
>> 590:             allocate = true;
> 
> Can we rename this boolean to `trusted` and set it to `false` when we assign it back to `dis.bytearr`? Even though that assignment will be redundant, calling it `trusted` is helpful to avoid causing security problems if we reorganize this code in the future.

When ascii != utflen, bytearr will be reused, and the name of `trusted` is not clear here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20903#discussion_r1761486696

From liach at openjdk.org  Tue Sep 17 03:29:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 03:29:31 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <bnc0FJRHGBQFTiy7-YbYx4cWVoXjndKW9N8sXUVDvhk=.ef5cae10-fe83-4e02-9245-d1d8ade23030@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
 <DJVUl2btPfuCt-HWiWA9Anumx_y0J9HR-W1QtdoIM9M=.4ccefc4d-6110-4401-bcb2-ab54374d2773@github.com>
 <bnc0FJRHGBQFTiy7-YbYx4cWVoXjndKW9N8sXUVDvhk=.ef5cae10-fe83-4e02-9245-d1d8ade23030@github.com>
Message-ID: <jaV5uvGfM5An7ZU65OevEJYK7-WvltsoQnLGanDV3xc=.d679e057-51ec-4eca-97f1-a9a36500e922@github.com>

On Mon, 16 Sep 2024 16:41:04 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/DataInputStream.java line 590:
>> 
>>> 588:         if (bytearr == null) {
>>> 589:             bytearr = new byte[utflen];
>>> 590:             allocate = true;
>> 
>> Can we rename this boolean to `trusted` and set it to `false` when we assign it back to `dis.bytearr`? Even though that assignment will be redundant, calling it `trusted` is helpful to avoid causing security problems if we reorganize this code in the future.
>
> When ascii != utflen, bytearr will be reused, and the name of `trusted` is not clear here.

I mean to add a `trusted = false;` when bytearr is reused; trusted will be clear there, and in the future it's less likely for programmers to accidentally leak the trusted array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20903#discussion_r1761571703

From duke at openjdk.org  Tue Sep 17 03:29:31 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 17 Sep 2024 03:29:31 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
Message-ID: <_U4swPeyCH2zxcq2DsSx-t3GIMfFSybflndcaYv2GvQ=.4f0c6fbb-732d-49ab-b476-6a0f23ba0646@github.com>

On Sun, 8 Sep 2024 07:52:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF

src/java.base/share/classes/java/io/DataInputStream.java line 602:

> 600:         int ascii = JLA.countPositives(bytearr, 0, utflen);
> 601:         if (ascii == utflen) {
> 602:             return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1);

Maybe?use `sun.nio.cs?.ISO_8859_1?.INSTANCE` instead in?order to?avoid initialising unused?charsets:
Suggestion:

            return new String(bytearr, 0, utflen, ISO_8859_1.INSTANCE);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20903#discussion_r1749167163

From liach at openjdk.org  Tue Sep 17 03:29:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 03:29:31 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <_U4swPeyCH2zxcq2DsSx-t3GIMfFSybflndcaYv2GvQ=.4f0c6fbb-732d-49ab-b476-6a0f23ba0646@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
 <_U4swPeyCH2zxcq2DsSx-t3GIMfFSybflndcaYv2GvQ=.4f0c6fbb-732d-49ab-b476-6a0f23ba0646@github.com>
Message-ID: <rhR929O0tR8AqlvVLRXzj9i66ZMKr2mZnCMuL4KgnZo=.45132ede-c3b4-416a-8511-19dda2d70627@github.com>

On Sun, 8 Sep 2024 10:05:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF
>
> src/java.base/share/classes/java/io/DataInputStream.java line 602:
> 
>> 600:         int ascii = JLA.countPositives(bytearr, 0, utflen);
>> 601:         if (ascii == utflen) {
>> 602:             return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1);
> 
> Maybe?use `sun.nio.cs?.ISO_8859_1?.INSTANCE` instead in?order to?avoid initialising unused?charsets:
> Suggestion:
> 
>             return new String(bytearr, 0, utflen, ISO_8859_1.INSTANCE);

We should use `StandardCharsets` as in most other standard usages. This method is not on bootstrap path, so readability is more important.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20903#discussion_r1749203988

From liach at openjdk.org  Tue Sep 17 04:01:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 04:01:07 GMT
Subject: RFR: 8162500: Receiver annotations of inner classes of local
 classes not found at runtime
In-Reply-To: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
References: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
Message-ID: <f9w8Ll-inrCpDBdLhf_flA0pIME2ZpM4ditQUYZyhso=.fb052209-eb8d-46c0-b994-f7719d039f45@github.com>

On Tue, 16 Jul 2024 18:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here
> 
>     public static Class<?> getLocalsMember() {
>         class Local {
>             class Member {
>                 @Annot(2635) Member(@Annot(2732) Local Local.this) {}
>             }
>         }
>         return Local.Member.class;
>     }
> 
> 
> The `Local` occurrences cannot be qualified with the enclosing class type, even if the local class may be compiled to capture the enclosing class.
> 
> However, core reflection had a bug where it looks for an enclosing class instead of a declaring class; this meant that for said `Local`, core reflection was treating the outer class as the top-level in type annotations, while the top level should be the local class instead. This patch fixes this bug.

Keep alive. Maybe some reviewer will be free at some point...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20200#issuecomment-2354455218

From duke at openjdk.org  Tue Sep 17 04:41:20 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 17 Sep 2024 04:41:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v11]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <4eB1-LVi9xoS-lksSPbpyf39ebjZvsaqKQrP0XSMOTE=.48731919-0181-4aeb-97f6-ea2f22ac3410@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  remove -ve tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/1ee4c1fe..aa163896

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=09-10

  Stats: 727 lines in 1 file changed: 0 ins; 364 del; 363 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From djelinski at openjdk.org  Tue Sep 17 06:09:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Sep 2024 06:09:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <MXCMOQcjdczxKA4rLdbgdCojzfrJ08vAA4Pze4xOfWs=.dae3de6d-cba0-4568-99df-02faeed74a47@github.com>

On Fri, 13 Sep 2024 20:41:27 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2308420140

From djelinski at openjdk.org  Tue Sep 17 06:32:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Sep 2024 06:32:06 GMT
Subject: RFR: 8339574: Behavior of File.is{Directory,File,Hidden} is not
 documented with respect to symlinks [v8]
In-Reply-To: <3HwQ0DoRX75LPI2nDwb4kYrs6XUCqwo6TovKWENRrIg=.bba9d8ec-14a6-4d89-be86-0dc1678975d1@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
 <3HwQ0DoRX75LPI2nDwb4kYrs6XUCqwo6TovKWENRrIg=.bba9d8ec-14a6-4d89-be86-0dc1678975d1@github.com>
Message-ID: <Urq0btvWu_TjZEcs09kUngi8FphQ1veKm3pC1qIWwOE=.1cd3cb37-0ba4-4a38-85ef-5ade8bf53faa@github.com>

On Mon, 16 Sep 2024 19:09:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8339574: Add symbolic link verbiage to File.deleteOnExit

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20878#pullrequestreview-2308484268

From jpai at openjdk.org  Tue Sep 17 06:34:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 06:34:31 GMT
Subject: RFR: 8286851: Deprecate for removal several of the undocumented java
 launcher options
Message-ID: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>

Can I please get a review of this change which proposes to deprecate several outdated and undocumented java launcher options? This addresses https://bugs.openjdk.org/browse/JDK-8286851.

Specifically, the non-standard launcher options `-verbosegc`, `-noclassgc`, `-verify`, `-verifyremote`, `-ss`, `-ms` and `-mx` will be deprecated for removal. With this change, a deprecation warning will be printed, if any of these options are used.

No new tests have been added for this change. Existing tests in tier1, tier2 and tier3 continue to pass.

I'll create a CSR shortly for this change.

-------------

Commit messages:
 - 8286851: Deprecate for removal several of the undocumented java launcher options

Changes: https://git.openjdk.org/jdk/pull/21031/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21031&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286851
  Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21031/head:pull/21031

PR: https://git.openjdk.org/jdk/pull/21031

From jbhateja at openjdk.org  Tue Sep 17 07:10:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:10:54 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v11]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <Ap3NewgtjOLyDG83B6DVwCc9OKRVfQFGmevbcNdYl9I=.a7fa66b4-1437-417d-9ef5-926e8061efac@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with two additional commits since the last revision:

 - Jcheck clearance
 - Review comments resolution.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/7c80bfce..29530047

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=09-10

  Stats: 402 lines in 41 files changed: 98 ins; 98 del; 206 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Tue Sep 17 07:10:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:10:54 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <0Ak63KM4JYdbOT33Q8XPcv096MKzjY6vyl4xZkapZwM=.6b92e423-9bd5-4109-a0b3-75dbeaf40315@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
 <0Ak63KM4JYdbOT33Q8XPcv096MKzjY6vyl4xZkapZwM=.6b92e423-9bd5-4109-a0b3-75dbeaf40315@github.com>
Message-ID: <jJKUBxW9OJSF-D6M0seaAivuvT8gjjBXQKiRM_GOS1U=.e620defe-737d-47a3-b0f6-29848aa73068@github.com>

On Mon, 16 Sep 2024 07:45:51 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
>
> src/hotspot/share/opto/vectornode.cpp line 2122:
> 
>> 2120:   // index format by subsequent VectorLoadShuffle.
>> 2121:   int cast_vopc = VectorCastNode::opcode(0, index_elem_bt, true);
>> 2122:   Node* index_byte_vec = phase->transform(VectorCastNode::make(cast_vopc, index_vec, T_BYTE, num_elem));
> 
> This cast assumes that the indices cannot have more than 8 bits. This would allow vector lengths of up to 256. This is fine for intel. But as far as I know ARM has in principle longer vectors - up to 2048 bytes. Should we maybe add some assert here to make sure we never badly truncate the index?

Shuffle overall is on our todo list, its a know limitation which we tried lifting once, yes you read it correctly, its a limitation for AARCH64 SVE once a 2048 bits vector systems are available, IIRC current max vector size on any available AARCH64 system is 256 bits, with Neoverse V2 they shrink the vector size back to 16 bytes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504446

From jbhateja at openjdk.org  Tue Sep 17 07:10:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:10:54 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <SKSw-FrhZoxCgHq1c5Nf361hGzjhHeAqAQrTTAXPJQM=.19c4f7aa-ded9-42ee-888f-58e8863fa65d@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <AgbqqlGF_TyM-5b4Zap10S1iLahRjwL-Kiq1vKJglyA=.c3809925-60f9-469f-a3e1-ae2b2c593f1a@github.com>
 <SKSw-FrhZoxCgHq1c5Nf361hGzjhHeAqAQrTTAXPJQM=.19c4f7aa-ded9-42ee-888f-58e8863fa65d@github.com>
Message-ID: <8QUaed-UNR5ura5MXAeccEXQgaSOUaM_JCHvrUUeCVE=.d895b3db-6e3c-4351-9147-81eb303536f9@github.com>

On Mon, 16 Sep 2024 07:27:44 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Please at least add a comment why you are not following my suggestion. I feel like the work I put in to review is not being respected when comments are just silently resolved without any action or comment.
>
> I really do think that `as_ConI()` would be the right thing here. In product it is just a cast, and in debug at least we have an assert.

DONE

**It just got overlooked @eme64, we respect reviewer suggestions and value the time you invest in polishing our patches, thanks again :-)**

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504618
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504671

From jbhateja at openjdk.org  Tue Sep 17 07:10:55 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:10:55 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <NfMEKeVYMB7GCEcfNyV-I2n-XjllH1tyN0Sd5b9MVJ0=.64e81e4d-5506-4002-bc52-2cacc0e590c9@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
 <NfMEKeVYMB7GCEcfNyV-I2n-XjllH1tyN0Sd5b9MVJ0=.64e81e4d-5506-4002-bc52-2cacc0e590c9@github.com>
Message-ID: <A-DVwQLh60xqkRl43Gu1RE_C1UFMy2X5rXhQ19_oSLk=.8ff78ec9-27eb-4a26-9456-f6819dac37f8@github.com>

On Mon, 16 Sep 2024 18:35:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 561:
> 
>> 559:         for (int i = 0; i < vlen; i++) {
>> 560:             int index = ((int)vecPayload1[i]);
>> 561:             res[i] = index >= vlen ? vecPayload3[index & (vlen - 1)] : vecPayload2[index];
> 
> This is incorrect as the index could be negative. You need to wrap in the range `[0, 2 * vlen - 1]` before the comparison and selection.
> 
> int index = ((int)vecPayload1[i]) & ((vlen << 1) - 1));
> res[i] = index < vlen ? vecPayload2[index] : vecPayload3[index - vlen];

Hi @PaulSandoz , we already pass wrapped indexes to this helper routine called from fallback implementation.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2974:
> 
>> 2972:     final $abstractvectortype$ selectFromTemplate(Class<? extends Vector<$Boxbitstype$>> indexVecClass,
>> 2973:                                                   $abstractvectortype$ v1, $abstractvectortype$ v2) {
>> 2974:         int twoVectorLen = length() * 2;
> 
> We should assert that the length is a power of two.

API only accepts vector parameters and there is no means though public facing API to create a vector of NPOT sizes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504366
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504318

From jbhateja at openjdk.org  Tue Sep 17 07:10:55 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:10:55 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
 <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>
Message-ID: <Is137G0qUyH_yIUAX-cGKmF9nzMwVdEUVgxsgV_yIn0=.b4dac5b1-d9b6-474d-93d7-95b7158164c8@github.com>

On Fri, 13 Sep 2024 14:43:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Original API did throw IndexOutOfBoundsException, but later on we have moved away from exception throwing semantics to wrapping semantics.
>> Please find details at following comment
>> https://github.com/openjdk/jdk/pull/20508#issuecomment-2306344606
>
> And do we test that the wrapping works correctly?

VectorAPI Jtreg framework is based on testNG, our custom data providers associated with various test methods ensure to generates range of values which are beyond valid index range, this should check the wrapping scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504894

From jbhateja at openjdk.org  Tue Sep 17 07:10:55 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:10:55 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <_U2DgK6DAW3ZJhozsMhwHzggUFpj5fnHdLJOoYFcNJA=.1875811f-458f-4834-bb94-339a8ff7360d@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
 <TJdub3APHGvoyNZzq5ygmDESYGtVZPIiHxFiv8Uod5w=.72f880ff-cd61-4642-a9c8-303ece301454@github.com>
 <aiBfNWaV87bKHJrLbdw6Hpd0Isn5Py3VJcJ-r4HUhcQ=.fc4f8b57-50da-4143-8748-d5684d0f77af@github.com>
 <O757o3aig_rEnL3ZedwJwXrol51JVmGQKAMLFtiYjtU=.671debb0-d536-4e8b-93d6-f23d4f3fd48b@github.com>
 <_U2DgK6DAW3ZJhozsMhwHzggUFpj5fnHdLJOoYFcNJA=.1875811f-458f-4834-bb94-339a8ff7360d@github.com>
Message-ID: <JW6Io530CqpirUkD4EsnGTbaZ76-5tiwzYaRFwguagU=.dac8dbab-f45b-476d-a9bd-6c73ec8d5fba@github.com>

On Mon, 16 Sep 2024 07:40:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Patch includes tests for all the species (combination of vector type and sizes), each vector kernel is validated against equivalent scalar implementation, scenario which you are referring is implicitly handled though tests.
>
> Ok, just so that I can relax, can you please point me to this test that would implicitly verify that the backend has chosen the correct vector size?

Each test method validates the intrinsic code against equivalent scalar implementation, it should catch if backend emits instruction with incorrect vector size.
https://github.com/openjdk/jdk/pull/20508/files#diff-95c582657bf90bef3530e67cb143865d070fd2e8e4538849e3dce6061b0d5f2dR4863

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1762504831

From asotona at openjdk.org  Tue Sep 17 07:14:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 17 Sep 2024 07:14:08 GMT
Subject: RFR: 8340132: Remove internal CpException for reading malformed
 utf8
In-Reply-To: <4b9JSdqSCVew2frracl6hRTFgNkhsddNM-HspAaKnYI=.362ac9e2-5453-4a65-87c8-6ad1c0d77a53@github.com>
References: <4b9JSdqSCVew2frracl6hRTFgNkhsddNM-HspAaKnYI=.362ac9e2-5453-4a65-87c8-6ad1c0d77a53@github.com>
Message-ID: <EwIVF0nMSdL2x7CEvKeV4CIMi44A8C_TcnZyUX-AD-A=.e59f3755-52ee-43a0-b9b9-7fb55ce5f3b0@github.com>

On Tue, 17 Sep 2024 03:24:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove an internal exception for invalid utf8 entry format; it should have been an IllegalArgumentException but was an arbitrary subtype of RuntimeException. Converted to throw ConstantPoolException, and consolidated into a single method to reduce code size.

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21027#pullrequestreview-2308589050

From jbhateja at openjdk.org  Tue Sep 17 07:14:57 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 07:14:57 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Missed code fragment from last review comment resolution.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/ec7c7553..a6f8ee8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From pminborg at openjdk.org  Tue Sep 17 07:27:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 07:27:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
Message-ID: <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>

On Mon, 16 Sep 2024 10:19:26 GMT, Kasper Nielsen <duke at openjdk.org> wrote:

> This would actually be super useful in a public API. I use the same "trick" in some of my projects. Not because I care too much about the classfile size. But it is just a lot easier on the eye.

While I understand it would be convenient, there is a reason we have checked exceptions in the public APIs. Users can create similar utility methods in their projects if they want to "hide" the exceptions as you say. If you wish to add public methods anyhow, I think we should consider this under a separate issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2354746829

From dholmes at openjdk.org  Tue Sep 17 07:40:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Sep 2024 07:40:05 GMT
Subject: RFR: 8286851: Deprecate for removal several of the undocumented
 java launcher options
In-Reply-To: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
References: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
Message-ID: <ZOg0pEhOZuCaLjTcXHx9YxLDLwLPAOR534zPt5F4MtE=.0e11d030-cbc8-4e70-adfd-1177fe8e2987@github.com>

On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate several outdated and undocumented java launcher options? This addresses https://bugs.openjdk.org/browse/JDK-8286851.
> 
> Specifically, the non-standard launcher options `-verbosegc`, `-noclassgc`, `-verify`, `-verifyremote`, `-ss`, `-ms` and `-mx` will be deprecated for removal. With this change, a deprecation warning will be printed, if any of these options are used.
> 
> No new tests have been added for this change. Existing tests in tier1, tier2 and tier3 continue to pass.
> 
> I'll create a CSR shortly for this change.

LGTM!

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21031#pullrequestreview-2308646316

From jpai at openjdk.org  Tue Sep 17 07:59:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 07:59:04 GMT
Subject: RFR: 8286851: Deprecate for removal several of the undocumented
 java launcher options
In-Reply-To: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
References: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
Message-ID: <AJQOd40pc34SUwxmEKnhgQW0ij9PAgTCVAdoWW4SQN4=.e47dfea0-989b-4d60-a67c-ed972266a8fb@github.com>

On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate several outdated and undocumented java launcher options? This addresses https://bugs.openjdk.org/browse/JDK-8286851.
> 
> Specifically, the non-standard launcher options `-verbosegc`, `-noclassgc`, `-verify`, `-verifyremote`, `-ss`, `-ms` and `-mx` will be deprecated for removal. With this change, a deprecation warning will be printed, if any of these options are used.
> 
> No new tests have been added for this change. Existing tests in tier1, tier2 and tier3 continue to pass.
> 
> I'll create a CSR shortly for this change.

A CSR is now ready for review for this change https://bugs.openjdk.org/browse/JDK-8340244

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21031#issuecomment-2354808407

From dholmes at openjdk.org  Tue Sep 17 08:58:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Sep 2024 08:58:05 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <AXQ_4yQfgalQP_ddQ_7hgL-p1z0IG7xKEmMdZF_VRZk=.0e797d2c-5f4d-47eb-9980-6bee356e3f5f@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
 <dQeeqloHkKcbCS8JJ3e2hOhl28TgWk1Z_LVeO5Mo2Rs=.756588f8-974d-4430-a98b-143f662e8ddb@github.com>
 <AXQ_4yQfgalQP_ddQ_7hgL-p1z0IG7xKEmMdZF_VRZk=.0e797d2c-5f4d-47eb-9980-6bee356e3f5f@github.com>
Message-ID: <H5hB6K8KuQdhccbhD6g9OWMOYZgXzJS5-_h5URDMmPg=.28999ec8-d637-4763-b315-bf5ca875cfbd@github.com>

On Mon, 16 Sep 2024 14:02:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> In the context of the 2 platforms - macosx and unix, the recursive invocation still continues to happen.
>> 
>> For macosx, the `CreateExecutionEnvironment` unconditionally, through an internal `MacOSXStartup` function, spawns a new thread (`pthread_create`). That thread is passed a function pointer pointing to the current executable/process' `main(...)` function (and thus made to execute afresh). That then triggers this recursion where `JLI_Launch` is called again and that then calls into `CreateExecutionEnvironment` all the way to `MacOSXStartup` function which has the necessary knowledge not to spawn another thread the second time.
>> 
>> For unix, in the `CreateExecutionEnvironment` function, there's a specific piece of code which determines whether or not `LD_LIBRARY_PATH` environment variable needs to be set or updated before loading the JVM. This decision of whether or not `LD_LIBRARY_PATH` needs to be updated or set is done in an internal function called `RequiresSetenv`. There are several rules which determine whether or not to set/update that environment variable. Rules like - is musl libc in use; or is the runtime environment AIX; or if the `LD_LIBRARY_PATH` is currently set, then whether the value in the environment variable matches some well known JVM library path patterns (like `lib/client`, `lib/server`). If any of these rules determine that the `LD_LIBRARY_PATH` needs to be set/updated, then the `CreateExecutionEnvironment` function will do the necessary updates to the environment variable value and and exec() the current process with that new value. This then triggers the recursion all the way from th
 e `JLI_Launch` back into this `CreateExecutionEnvironment` (which has the necessary knowledge not to exec() once more).
>
>> For macosx, the CreateExecutionEnvironment unconditionally, through an internal MacOSXStartup function, spawns a new thread (pthread_create).
> 
> I forgot to note that, the reason for spawning this new thread is explained as a code comment (unrelated to the changes in this PR) on the `MacOSXStartup` function and it says:
> 
> 
> /*
> * Mac OS X mandates that the GUI event loop run on very first thread of
> * an application. This requires that we re-call Java's main() on a new
> * thread, reserving the 'main' thread for Cocoa.
> */

That aside, the launcher always tries to spawn a new thread because bad stuff can happen on some OS if we try to make the process primordial thread a JavaThread (e.g. you can't enforce stack size limits).

But I remain unclear as to why the new thread has to "start again" rather than continuing with the launch process- it is even called ContinueInNewThread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1762683203

From dholmes at openjdk.org  Tue Sep 17 09:06:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Sep 2024 09:06:05 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <_6YXev5mQRg2LEt8oWISVsx8LrwUZVG9jZP2OV0OeZQ=.52a09dcc-4d84-43d7-bc7d-ec9eaf9843cf@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <_6YXev5mQRg2LEt8oWISVsx8LrwUZVG9jZP2OV0OeZQ=.52a09dcc-4d84-43d7-bc7d-ec9eaf9843cf@github.com>
Message-ID: <IeNbbnMEgwjWnd3IQJ44BDj17WWQAIEbwi6R_hqESFE=.3b4d6ebb-0526-4253-888f-0684d1e4b7b8@github.com>

On Mon, 16 Sep 2024 13:55:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment improvements

Okay I had expected (hoped for?) more simplifications but it seems a lot of the complexity of the launch procedure remains. I think basically this just gets rid  of the data model and mJRE stuff and moves the rest out of SelectVersion.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20997#pullrequestreview-2308876241

From redestad at openjdk.org  Tue Sep 17 09:33:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Sep 2024 09:33:37 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating LambdaForms
Message-ID: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>

This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.

Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.

Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.

-------------

Commit messages:
 - Avoid calling MT.invokerType() when creating LambdaForms

Changes: https://git.openjdk.org/jdk/pull/21035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340280
  Stats: 53 lines in 6 files changed: 19 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/21035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21035/head:pull/21035

PR: https://git.openjdk.org/jdk/pull/21035

From jvernee at openjdk.org  Tue Sep 17 10:52:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 17 Sep 2024 10:52:04 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms
In-Reply-To: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
Message-ID: <fM_mi6sbM84vzecUTmTHpuvdF50FZhj9EGijbrPydrY=.cf7cdb37-e22a-454e-b6e7-7b16579420c8@github.com>

On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
> 
> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
> 
> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21035#pullrequestreview-2309391179

From jpai at openjdk.org  Tue Sep 17 11:12:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 11:12:06 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <_6YXev5mQRg2LEt8oWISVsx8LrwUZVG9jZP2OV0OeZQ=.52a09dcc-4d84-43d7-bc7d-ec9eaf9843cf@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <_6YXev5mQRg2LEt8oWISVsx8LrwUZVG9jZP2OV0OeZQ=.52a09dcc-4d84-43d7-bc7d-ec9eaf9843cf@github.com>
Message-ID: <pjffeE4m8LVWVoHWpIRNLmWBls7ZqV8ad69RQwftEG4=.4a85fa6c-1900-42ef-b9b2-42ce5adb650c@github.com>

On Mon, 16 Sep 2024 13:55:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment improvements

Thank you for the review David.

> Okay I had expected (hoped for?) more simplifications but it seems a lot of the complexity of the launch procedure remains.

In general, I've several changes that are lined up for cleaning up the launcher code. Some deprecations, some clean up and some fixes. I plan to propose those changes in the coming days.

This current PR was a small isolated step towards getting the launcher to a state where we can get rid of jar manifest processing within the C code (there are a few additional things needed as a separate PR to help us reach there).

This code and the area is new to me, I welcome any additional inputs that you have in mind in updating/changing or cleaning up this launcher code.

> I think basically this just gets rid of the data model and mJRE stuff and moves the rest out of SelectVersion.

Now that you mention it, one part of the changes in this PR, moves the checks and error reporting for the `-version:`, `-jre-restrict-search` and `-jre-no-restrict-search` options to the `ParseArguments` function. I think we can just get rid of that code and let those options be considered as just another unknown option to the launcher. I can open a CSR linked to this current PR to formalize that change. That would also mean that the `MultipleJRERemoved` test can also be deleted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20997#issuecomment-2355365863

From jpai at openjdk.org  Tue Sep 17 11:19:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 11:19:04 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <H5hB6K8KuQdhccbhD6g9OWMOYZgXzJS5-_h5URDMmPg=.28999ec8-d637-4763-b315-bf5ca875cfbd@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Orx-9x3G2f-RtVbkoEWDfye8DKfMOd3XdA_hd4AVBPs=.9562cde8-7d2c-4c8f-b447-60f19f51f6c9@github.com>
 <dQeeqloHkKcbCS8JJ3e2hOhl28TgWk1Z_LVeO5Mo2Rs=.756588f8-974d-4430-a98b-143f662e8ddb@github.com>
 <AXQ_4yQfgalQP_ddQ_7hgL-p1z0IG7xKEmMdZF_VRZk=.0e797d2c-5f4d-47eb-9980-6bee356e3f5f@github.com>
 <H5hB6K8KuQdhccbhD6g9OWMOYZgXzJS5-_h5URDMmPg=.28999ec8-d637-4763-b315-bf5ca875cfbd@github.com>
Message-ID: <In_qEf8abbKmOVUEt4ChQQJJF5hge2X_GPxVlTij-I0=.573da700-a8f0-4057-91c8-f4030772bc8e@github.com>

On Tue, 17 Sep 2024 08:55:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But I remain unclear as to why the new thread has to "start again" rather than continuing with the launch process

That's unclear to me as well. As a separate task, I do plan to look into the historical changes in this area to understand better and see if we can improve this part to not restart afresh right from the beginning and instead continue the launch process from a specific point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1763054647

From jpai at openjdk.org  Tue Sep 17 11:27:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 11:27:39 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v7]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  treat -version: -jre-restrict-search and -jre-no-restrict-search like any other unknown option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/e0928749..04bf9f4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=05-06

  Stats: 233 lines in 3 files changed: 0 ins; 233 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From jpai at openjdk.org  Tue Sep 17 11:32:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Sep 2024 11:32:04 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v6]
In-Reply-To: <pjffeE4m8LVWVoHWpIRNLmWBls7ZqV8ad69RQwftEG4=.4a85fa6c-1900-42ef-b9b2-42ce5adb650c@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <_6YXev5mQRg2LEt8oWISVsx8LrwUZVG9jZP2OV0OeZQ=.52a09dcc-4d84-43d7-bc7d-ec9eaf9843cf@github.com>
 <pjffeE4m8LVWVoHWpIRNLmWBls7ZqV8ad69RQwftEG4=.4a85fa6c-1900-42ef-b9b2-42ce5adb650c@github.com>
Message-ID: <zBHozF54RtkREZf7r1xyjBHTz2S7-o1fxVXd92Ba-KM=.7ffb7909-503c-433b-a404-3419389fe3ae@github.com>

On Tue, 17 Sep 2024 11:09:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Now that you mention it, one part of the changes in this PR, moves the checks and error reporting for the -version:, -jre-restrict-search and -jre-no-restrict-search options to the ParseArguments function. I think we can just get rid of that code and let those options be considered as just another unknown option to the launcher.

I've now updated the PR to consider these 3 options just like any other unknown option. The previous existing `MultipleJRERemoved` is no longer needed and that's been removed too.

> I can open a CSR linked to this current PR to formalize that change. 

Thinking more, I don't think a CSR is needed here. In the current mainline, even without these proposed changes, if I launch `java` with either of these 3 options then the launch fails with an error:


java -jre-no-restrict-search Foo             
Error: Specifying an alternate JDK/JRE is no longer supported.
  The related flags -jre-restrict-search | -jre-no-restrict-search are also no longer valid.
Error: Specifying an alternate JDK/JRE is no longer supported.
  The related flags -jre-restrict-search | -jre-no-restrict-search are also no longer valid.
Unrecognized option: -jre-no-restrict-search
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


With the latest proposed change in this PR, the java launch with continue to fail with a (generic) error:


Unrecognized option: -jre-no-restrict-search
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


So I don't think this deserves a CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20997#issuecomment-2355425729

From liach at openjdk.org  Tue Sep 17 12:20:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 12:20:10 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
Message-ID: <a0b51xPBrzb9yp-MkatoyNF4k6IgPq8XSiiw7hWRMPE=.1a17ec9c-e7b6-4968-aed8-d5b5fa324e18@github.com>

On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> 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 five additional commits since the last revision:
> 
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

I think the original poster means to find a VH in the lookup class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355564774

From liach at openjdk.org  Tue Sep 17 12:31:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 12:31:06 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms
In-Reply-To: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
Message-ID: <qubH5OfcMb3zbc_mKHpbMAnMU9DEiyQLSxVqAs6OJys=.c67143e8-440a-43cd-bc35-ff40b92e8ccd@github.com>

On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
> 
> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
> 
> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21035#pullrequestreview-2309609822

From duke at openjdk.org  Tue Sep 17 12:37:05 2024
From: duke at openjdk.org (Kasper Nielsen)
Date: Tue, 17 Sep 2024 12:37:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <a0b51xPBrzb9yp-MkatoyNF4k6IgPq8XSiiw7hWRMPE=.1a17ec9c-e7b6-4968-aed8-d5b5fa324e18@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
 <a0b51xPBrzb9yp-MkatoyNF4k6IgPq8XSiiw7hWRMPE=.1a17ec9c-e7b6-4968-aed8-d5b5fa324e18@github.com>
Message-ID: <HKg-Ow0UJCJ_I_31yB6qRVYbZ0puyJwCJzBdBJ6BIms=.1ec9cc1a-74de-40cb-998b-8c64a648824f@github.com>

On Tue, 17 Sep 2024 12:17:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think the original poster means to find a VH in the lookup class.

I actually meant what Per is hinting at. Defining static MethodHandle/VarHandle in a class at class initialization time, without the ceremony of handling ReflectiveOperationException and throwing ExceptionInInitializerError. 

I could be mistaken but I think this is probably how most MethodHandle/VarHandles are defined.
But I understand reason not to add these methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355614436

From alanb at openjdk.org  Tue Sep 17 12:37:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Sep 2024 12:37:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
 <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>
Message-ID: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com>

On Tue, 17 Sep 2024 07:24:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>  If you wish to add public methods anyhow, I think we should consider this under a separate issue.

I think it's a request for 10+ find methods to sit along the existing methods so it might be confusing too.

I think your proposal looks generally okay, not sure about naming it "MethodHandlesInternal" with "internal" in the package name as it's more like a class of utility methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355617297

From pminborg at openjdk.org  Tue Sep 17 12:59:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 12:59:13 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
Message-ID: <Jg6ji-eSBCMgCv8d5AbCmrTMX1BDtnoSeMWql_nWFgk=.1e617f45-595e-415a-be77-6b43dd540ead@github.com>

On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> 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 five additional commits since the last revision:
> 
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

It is possible to create a project-specific utility method that can unwrap several methods like this:


    @FunctionalInterface
    public interface LookupFunction<R> {
        R apply(MethodHandles.Lookup lookup,
                Class<?> refc,
                String name,
                MethodType type) throws NoSuchMethodException, IllegalAccessException;
    }

    public static <R> R unwrap(LookupFunction<R> lookupFunction,
                               MethodHandles.Lookup lookup,
                               Class<?> refc,
                               String name,
                               MethodType type) {
        try {
            return lookupFunction.apply(lookup, refc, name, type);
        } catch (ReflectiveOperationException e) {
            throw new InternalError(e);
        }
    }

    static final MethodHandle MH_SCALE = MethodHandlesUtil.unwrap(MethodHandles.Lookup::findVirtual,
            MethodHandles.lookup(), MemoryLayout.class, "scale", MethodType.methodType(long.class, long.class, long.class));

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355690263

From pminborg at openjdk.org  Tue Sep 17 13:05:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 13:05:24 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update javadoc
 - Rename utility class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/e2e935b2..7f140322

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=02-03

  Stats: 82 lines in 31 files changed: 0 ins; 0 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From swen at openjdk.org  Tue Sep 17 13:16:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 17 Sep 2024 13:16:10 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v6]
In-Reply-To: <ZFEPGIME5kpOe7NolvRTZwzNSMb2Rmp14KJneJ1-m6A=.3a13650d-de35-4392-910f-5cc5d201f441@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <9ls0kBdzdPcFkhX7afFDPyt77Td9vF76d0zhH6qAuSw=.64bc9876-c3a2-43b9-ba2d-3f170f7d6956@github.com>
 <R2ajMscuvK6luanLYQNu7YS21oNjSlEvFiW4t7E2lkc=.d70905b2-d4f3-45dc-9a26-91f9db4abea8@github.com>
 <ZFEPGIME5kpOe7NolvRTZwzNSMb2Rmp14KJneJ1-m6A=.3a13650d-de35-4392-910f-5cc5d201f441@github.com>
Message-ID: <NTU2H-oqPujViSd7tDlqgC-dFNWNAdqYjQeoQk-CR2I=.2646d02a-003f-4bf6-8011-a62370d1e509@github.com>

On Tue, 10 Sep 2024 13:24:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 529:
>> 
>>> 527:                 mh = simpleConcat3(paramType0);
>>> 528:                 mh = MethodHandles.insertArguments(mh, 0, prefix);
>>> 529:                 return MethodHandles.filterArguments(mh, 1, objectStringifier());
>> 
>> While this is a fun trick it seems like there's a non-trivial cost here? We'd go down different paths and generate different classes for `"foo" + bar + baz` and `"foo" + bar + " .. " + baz` with this. Special casing when we get the added shapes for more or less free (plain `simpleConcat()`) is a different matter but here you need to construct a new couple of shapes with `insert-` and `filterArguments`.
>> 
>> (Check on paramType1 could be `!paramType1.isPrimitive()`)
>
> I'm also not sure how much cost the simpleConcat handling of the 2 parameters would bring, I've removed that, and this is more appropriately implemented by the InlineHiddenClassStrategy.

If we handle the null values of prefix and suffix, the cost of supporting the 2-parameter scenario will be much lower.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20726#discussion_r1763226369

From eirbjo at openjdk.org  Tue Sep 17 13:37:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 17 Sep 2024 13:37:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
 <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>
 <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com>
Message-ID: <idoSt8VsBJ1PYIoiy0zHD89E2OOTDfRPRI8pyKaFIM8=.2e4307e5-8bd0-416a-a1f6-2b79998ffad7@github.com>

On Tue, 17 Sep 2024 12:33:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think your proposal looks generally okay, not sure about naming it "MethodHandlesInternal" with "internal" in the package name as it's more like a class of utility methods.

Perhaps `MethodHandlesSupport`, like `jdk.internal.util.ArraysSupport`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355825352

From liach at openjdk.org  Tue Sep 17 13:40:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 13:40:07 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
Message-ID: <eLXp4P8opgrW7KQCOT3hHpeQlfE7qbI9Y_iXhhdyD5c=.2b7585df-769d-4884-a232-f28959da4bb8@github.com>

On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update javadoc
>  - Rename utility class

I think a better approach to this problem might be converting these static final MethodHandle/VarHandle to class-file constants (Constant_MethodHandle for MH, Constant_Dynamic for VH), see JEP 303.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355833854

From redestad at openjdk.org  Tue Sep 17 13:40:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Sep 2024 13:40:08 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <g7ivyoSxHyB-07Gc2eF3t_et1hFTr8ovm4tB8Z7jni0=.10d9d5e3-af9a-410d-9070-da8f118e71c6@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Looking into this I see that `internalNameHash` (and `pow31`) shows up in startup profiles - making the change more or less neutral on bytecode counts. `pow31` seem to be a contributor to the regression in the `internalNameLookup` micro.

Since most common internal names are relatively small (`java/lang/String` etc) I wonder if a small memoized lookup table is profitable? Ran with a naive one containing pow31(0 - 63) and see a 1.08x speedup in `internalNameLookup`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2355834197

From liach at openjdk.org  Tue Sep 17 13:43:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 13:43:10 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <5cd6mbKDO9wN5EjSyvSrdEYf4RYqSAGiKp8vizHIllM=.0496a6b6-2a0e-4876-84f5-639344633f0b@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Indeed, the small table means we omit one multiplication for 2-octal-digit cases. Do you initialize that table by multiplication or explicit array initialization?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2355843816

From liach at openjdk.org  Tue Sep 17 13:46:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 13:46:08 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <NggppXMYaI6Cr8wJZ3O6OKzrQRYETGUvU-EoNPKazcU=.613a1afb-b007-4a27-b45a-ef285f0b140d@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

This should be ready to integrate. Feel free to issue the integrate command.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21020#issuecomment-2355856248

From liach at openjdk.org  Tue Sep 17 13:48:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 13:48:11 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <NE8ybPWsna53C8KYlmaIW-MheLZdq3-PiTlG1wjYHyI=.e7f62757-d467-42e1-bd49-24b5e8aba0db@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Also note that the scenario this patch aims to tackle is when a ClassDesc is repeatedly used in bytecode generation: such as repeated occurrences of `CD_String`, or `CD_MethodHandle` for `invokeExact`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2355861912

From rriggs at openjdk.org  Tue Sep 17 14:07:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Sep 2024 14:07:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
Message-ID: <3-8Pao_PVgev-cXH5tS4knP3CGHAgYbBsFf3hNc5ttY=.32535d56-044d-481d-8342-c44ed0811b91@github.com>

On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update javadoc
>  - Rename utility class

Overall looks good. Having a concise source construct representing these factories will enable jlink or similar pre-processing steps to optimize.

The new class will be lonesome in its own package.
I'd shorten the classname to "MHUtil" making the source lines more readable.

src/java.base/share/classes/jdk/internal/invoke/MethodHandlesUtil.java line 35:

> 33: /**
> 34:  * This class contains a number of static factories for certain
> 35:  * VarHandle/MethodHandle variants.

I'd write this as a more concise 1st line comment.  "This class contains a number of" is noise.
"Utility static factories of method handles for fields and methods."
or similar.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20972#pullrequestreview-2309856171
PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1763305393

From liach at openjdk.org  Tue Sep 17 14:14:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 14:14:12 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
Message-ID: <I0hstTiT2wzuVEucmp7KcAk5qXsK4C6U90Izjdd1DUM=.ad86d79d-c0e1-48c9-aea7-7a1415514a75@github.com>

On Tue, 13 Aug 2024 23:41:06 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Fix copyright years.

@raphw Your patch is ready and you can integrate it with the `/integrate` command, just in case this got forgotten. I can clean up the test case later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20535#issuecomment-2355956774

From pminborg at openjdk.org  Tue Sep 17 14:25:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 14:25:42 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v5]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <o--l6IC9JxuNJ9SvI7YURxiImmj-vqRd0pWC2nWWBRc=.6f3881df-6e7e-4446-9255-e6fe1a5b6b57@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

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 nine additional commits since the last revision:

 - Merge branch 'master' into internal-mh-util
 - Rename class and shorten JavaDoc
 - Update javadoc
 - Rename utility class
 - Move to new package and add overload
 - Merge branch 'master' into internal-mh-util
 - Rename and reformat
 - Fix copyright headers
 - Introduce MethodHandlesInternal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/7f140322..a1444c28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=03-04

  Stats: 121988 lines in 261 files changed: 121641 ins; 172 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From redestad at openjdk.org  Tue Sep 17 15:08:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Sep 2024 15:08:10 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <7gBAf3l53D0uYJUSoGodEAXmk4HUt_TFwSsGBbjsDFs=.4c4b865c-e43f-4dbc-b982-c2f786d004c1@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Improving `pow31` should help a little each distinct `classEntry(ClassDesc)`, no? 

Perhaps would be good with a micro variant doing what `identicalLookup` does but on a fresh `ConstantPoolBuilder.of()` each time. There'll be a lot of unrelated noise in such a variant, and we're hiding costs of `String.hashCode`, but it'll tell us something about the first-time insertion cost.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2356163426

From duke at openjdk.org  Tue Sep 17 15:10:07 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 17 Sep 2024 15:10:07 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <eLXp4P8opgrW7KQCOT3hHpeQlfE7qbI9Y_iXhhdyD5c=.2b7585df-769d-4884-a232-f28959da4bb8@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
 <eLXp4P8opgrW7KQCOT3hHpeQlfE7qbI9Y_iXhhdyD5c=.2b7585df-769d-4884-a232-f28959da4bb8@github.com>
Message-ID: <7988GQeBo-xYw7i-H9i6fTkQein298GVmZPJSgt1BIw=.773c89ab-ea3a-4c8c-9ae4-7817fb5bf744@github.com>

On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update javadoc
>>  - Rename utility class
>
> I think a better approach to this problem might be converting these static final MethodHandle/VarHandle to class-file constants (Constant_MethodHandle for MH, Constant_Dynamic for VH), see JEP 303.

In my projects I usually just use the `ConstantBootstraps` method directly, which avoids the try/catch (but does not avoid needing a lookup). In my mind I imagine eventually writing a tool which post-processes my classes and replaces all `private static final Xxx xxx = ConstantBootstraps.xxx()` with dynamic constants (similarly, I guess, to what @liach suggested). But maybe just using the existing `ConstantBootstraps` methods is a good stepping stone towards a JEP-303 kind of solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2356168738

From winterhalter at openjdk.org  Tue Sep 17 15:23:41 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Tue, 17 Sep 2024 15:23:41 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v5]
In-Reply-To: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
Message-ID: <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>

> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:

  8337302: Add comment with class that is created.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20535/files
  - new: https://git.openjdk.org/jdk/pull/20535/files/10d73b6c..e9513627

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20535&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20535&range=03-04

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20535.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20535/head:pull/20535

PR: https://git.openjdk.org/jdk/pull/20535

From liach at openjdk.org  Tue Sep 17 15:27:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 15:27:07 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v5]
In-Reply-To: <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>
Message-ID: <KnkLYWOHayXSYDfMS1pCKsnFR8DrB1e6UMuM6nOhsAU=.53e71585-04d5-41a1-a53f-16b71f131e7d@github.com>

On Tue, 17 Sep 2024 15:23:41 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Add comment with class that is created.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20535#pullrequestreview-2310095624

From winterhalter at openjdk.org  Tue Sep 17 15:27:08 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Tue, 17 Sep 2024 15:27:08 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <I0hstTiT2wzuVEucmp7KcAk5qXsK4C6U90Izjdd1DUM=.ad86d79d-c0e1-48c9-aea7-7a1415514a75@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
 <I0hstTiT2wzuVEucmp7KcAk5qXsK4C6U90Izjdd1DUM=.ad86d79d-c0e1-48c9-aea7-7a1415514a75@github.com>
Message-ID: <IpqsJezqQN34MdiRcdQtS84dK-kJzHQHhdWh_t8rWjc=.07f48b07-271f-4e86-b2e1-cf7f92ef55ab@github.com>

On Tue, 17 Sep 2024 14:11:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337302: Fix copyright years.
>
> @raphw Your patch is ready and you can integrate it with the `/integrate` command, just in case this got forgotten. I can clean up the test case later.

@liach I forgot about this over the pending CSR, sorry. I added the code comment as requested to show of the generated class. Does this need another approval before I can run integrate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20535#issuecomment-2356232829

From winterhalter at openjdk.org  Tue Sep 17 15:27:09 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Tue, 17 Sep 2024 15:27:09 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <bxnN1OfVCtIen4iUXaiCzyFxOjiGp92d1OlpNzIRVO4=.8633b068-9b82-42c4-a4b1-3ce17d3996a4@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
 <MvL8iMzp_fXIy9_gc_3xBF58bgdZJRfRtFZpmaoX4EU=.5134e96b-e52e-4f57-87e2-c333fe6a99b0@github.com>
 <bxnN1OfVCtIen4iUXaiCzyFxOjiGp92d1OlpNzIRVO4=.8633b068-9b82-42c4-a4b1-3ce17d3996a4@github.com>
Message-ID: <mM_NHr6iOXTqc_vuiD8a0QoplCPoJx0Fg2SGD59R6xE=.f5b7f063-ca89-4c3f-b516-17b5047b8f73@github.com>

On Fri, 16 Aug 2024 04:46:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 43:
>> 
>>> 41: public class TestMissingTypeVariable {
>>> 42: 
>>> 43:     public static void main(String[] args) throws Exception {
>> 
>> To make the test more understandable to casual readers, I suggest putting the corresponding source code, as much as possible, as a comment.
>
> An alternative approach could be to write a package-private or nested class in the same file:
> 
> static class Generic<T> {
>     T field;
> }
> 
> // ...
> 
> var cf = ClassFile.of();
> var generic = cf.parse(Path.of(System.getProperty("test.classes"), "TestMissingTypeVariable$Generic.class"));
> var result = cf.transformClass(generic, ClassTransform.dropping(ce -> ce instanceof SignatureAttribute);
> var missing = ByteCodeLoader.load("TestMissingTypeVariable$Generic", result);
> // proceed
> 
> 
> Would be more straightforward to readers.

I added a comment, I think that makes it clearest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1763447133

From liach at openjdk.org  Tue Sep 17 15:49:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 15:49:06 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v5]
In-Reply-To: <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>
Message-ID: <Z0I_8fzFija3Roz6VjGO2hsII1VUz8NIeqdkCFBBm6k=.546f0a78-94ef-4ce8-b044-2154c06c6bca@github.com>

On Tue, 17 Sep 2024 15:23:41 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Add comment with class that is created.

I think you have addressed the problems; we usually wait about 24 hours in case people are interested to review the latest push.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20535#issuecomment-2356304269

From bpb at openjdk.org  Tue Sep 17 15:53:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Sep 2024 15:53:11 GMT
Subject: Integrated: 8339574: Behavior of File.is{Directory, File,
 Hidden} is not documented with respect to symlinks
In-Reply-To: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
References: <yWztQ1wFrP7t5kLwEy8tfuaI1_FRi1lTrCEgkhV3xmw=.9d3880dc-3659-4fe9-9637-1ea3ec821f4b@github.com>
Message-ID: <syamY8XgRyUwyiFhkarkc-ydMc24D2XZKLFkvu7OKLw=.b08965fe-38cc-4c9d-a8a3-747e1b1b4c7e@github.com>

On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and `isHidden` behave when the `File` represents a symbolic link.

This pull request has now been integrated.

Changeset: 64e3a9ee
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64e3a9ee91a6ae939e479a10cfc597e628c571e5
Stats:     63 lines in 4 files changed: 43 ins; 0 del; 20 mod

8339574: Behavior of File.is{Directory,File,Hidden} is not documented with respect to symlinks

Reviewed-by: djelinski, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20878

From duke at openjdk.org  Tue Sep 17 16:12:11 2024
From: duke at openjdk.org (duke)
Date: Tue, 17 Sep 2024 16:12:11 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <bvZ4K-3glON0sarsivyiPfT3nmHmzeTWMoZKgpVtBmA=.748f383d-8748-47dd-923a-5102f0be62a0@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

@dmlloyd 
Your change (at version d74e7908602eb50c8a89ee5767aa97d592e9fc91) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21020#issuecomment-2356356113

From duke at openjdk.org  Tue Sep 17 16:28:08 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 17 Sep 2024 16:28:08 GMT
Subject: Integrated: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <8kl6jH70cj3DSnG0akRy-VCzWzb1QLFsPYWPQ7Ac5Fs=.10cf8592-97c2-4d98-95c0-b5101b68f113@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

This pull request has now been integrated.

Changeset: 3e14fb9c
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e14fb9c16e4ac3ad3c565059c534cfeacb45c7b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8340200: Misspelled constant `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21020

From psandoz at openjdk.org  Tue Sep 17 17:03:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 17:03:14 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <A-DVwQLh60xqkRl43Gu1RE_C1UFMy2X5rXhQ19_oSLk=.8ff78ec9-27eb-4a26-9456-f6819dac37f8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
 <NfMEKeVYMB7GCEcfNyV-I2n-XjllH1tyN0Sd5b9MVJ0=.64e81e4d-5506-4002-bc52-2cacc0e590c9@github.com>
 <A-DVwQLh60xqkRl43Gu1RE_C1UFMy2X5rXhQ19_oSLk=.8ff78ec9-27eb-4a26-9456-f6819dac37f8@github.com>
Message-ID: <iuAUE_VY-wM0XbTVVTsFm_pSrtLdxT-KR0J_5fkeV_M=.76aa4318-f747-4e9a-86a9-baf4e7fd4ccf@github.com>

On Tue, 17 Sep 2024 07:02:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 561:
>> 
>>> 559:         for (int i = 0; i < vlen; i++) {
>>> 560:             int index = ((int)vecPayload1[i]);
>>> 561:             res[i] = index >= vlen ? vecPayload3[index & (vlen - 1)] : vecPayload2[index];
>> 
>> This is incorrect as the index could be negative. You need to wrap in the range `[0, 2 * vlen - 1]` before the comparison and selection.
>> 
>> int index = ((int)vecPayload1[i]) & ((vlen << 1) - 1));
>> res[i] = index < vlen ? vecPayload2[index] : vecPayload3[index - vlen];
>
> Hi @PaulSandoz , we already pass wrapped indexes to this helper routine called from fallback implementation.

Opps yes, the masking was throwing me off.

Can you please add a comment and/or rename the parameters e.g., so `v1` is renamed to `wrappedIndex`?
Also i would recommend not doing the masking, it is very misleading and instead do the subtraction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1763582764

From psandoz at openjdk.org  Tue Sep 17 17:07:16 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 17:07:16 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <A-DVwQLh60xqkRl43Gu1RE_C1UFMy2X5rXhQ19_oSLk=.8ff78ec9-27eb-4a26-9456-f6819dac37f8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
 <NfMEKeVYMB7GCEcfNyV-I2n-XjllH1tyN0Sd5b9MVJ0=.64e81e4d-5506-4002-bc52-2cacc0e590c9@github.com>
 <A-DVwQLh60xqkRl43Gu1RE_C1UFMy2X5rXhQ19_oSLk=.8ff78ec9-27eb-4a26-9456-f6819dac37f8@github.com>
Message-ID: <uRNylIpLaFf8BvwS9VKpmddywqRTPrxpLrkIgwtQT4c=.18efbb74-4f96-4b5a-be16-e37983e8a374@github.com>

On Tue, 17 Sep 2024 07:02:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2974:
>> 
>>> 2972:     final $abstractvectortype$ selectFromTemplate(Class<? extends Vector<$Boxbitstype$>> indexVecClass,
>>> 2973:                                                   $abstractvectortype$ v1, $abstractvectortype$ v2) {
>>> 2974:         int twoVectorLen = length() * 2;
>> 
>> We should assert that the length is a power of two.
>
> API only accepts vector parameters and there is no means though public facing API to create a vector of NPOT sizes. https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#L842C58-L843C27

You missed the first bit of the sentence linked to "With the possible exception of the {@linkplain VectorShape#S_Max_BIT maximum shape}".

In generally the specification avoids assuming POT where it is not explicitly stated (i.e., the constant shapes). In this case we align with the specification of `VectorShuffle::wrapIndex`. We don't need to implement NPOT but we need a reminder in the implementation where we make that assumption.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1763587293

From rgiulietti at openjdk.org  Tue Sep 17 17:14:12 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Sep 2024 17:14:12 GMT
Subject: Integrated: 8339934: Simplify Math.scalb(double) method
In-Reply-To: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
References: <ABXk7ILcOHOtgonwhyAGjLQe8TY1jkXwo5FYmMUNKBY=.7330e1e3-526e-4289-9a7d-4ac962031fc6@github.com>
Message-ID: <xaEIKGOBBZmR5kMbdGhL6OWk4pYJIZ8pKyhzwnSS_qk=.82854597-e8c5-4b1f-8095-5c84b6b73112@github.com>

On Wed, 11 Sep 2024 12:45:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> `Math.scalb(double)` can be simplified, removing a loop and using larger/smaller factors.

This pull request has now been integrated.

Changeset: 28d009ce
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28d009ce0ecd4369351de859c491831b7f7bbb28
Stats:     65 lines in 1 file changed: 11 ins; 35 del; 19 mod

8339934: Simplify Math.scalb(double) method

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/20948

From alanb at openjdk.org  Tue Sep 17 17:35:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Sep 2024 17:35:08 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <OIwGedBkGoPsYGqQeh5qeMfxblh9QKGaUd4lAotAhP4=.a1b56410-e240-4c80-b137-c59763e7d263@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

Looks like test/jdk/jdk/classfile/OptionsTest.java was missed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21020#issuecomment-2356518606

From liach at openjdk.org  Tue Sep 17 17:53:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 17:53:10 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
Message-ID: <C9_VFUet-kwYkGO-cOrvN3rTAQSxU7wLB5apGTdOXl0=.d248c35f-783a-412b-a910-e2fb6761515b@github.com>

On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small change to fix a misspelling. The constant is not used directly; rather it is used by ordinal, which explains why the error was not found sooner.

Created https://bugs.openjdk.org/browse/JDK-8340323 to fix this test failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21020#issuecomment-2356555615

From liach at openjdk.org  Tue Sep 17 18:08:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 18:08:36 GMT
Subject: RFR: 8340323: Test jdk/classfile/OptionsTest.java fails after
 JDK-8340200
Message-ID: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>

A rename to a typo in preview enum constants missed a usage in tier1 tests. This fixes the typo.

-------------

Commit messages:
 - 8340323: Test jdk/classfile/OptionsTest.java fails after JDK-8340200

Changes: https://git.openjdk.org/jdk/pull/21044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340323
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21044/head:pull/21044

PR: https://git.openjdk.org/jdk/pull/21044

From alanb at openjdk.org  Tue Sep 17 18:12:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Sep 2024 18:12:04 GMT
Subject: RFR: 8340323: Test jdk/classfile/OptionsTest.java fails after
 JDK-8340200
In-Reply-To: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>
References: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>
Message-ID: <awy1o_mV67-j_h2c2Zq1giZEuhFUNoBQ9Zx91zs00jw=.cb27f20d-1924-459d-9370-a116d6447c42@github.com>

On Tue, 17 Sep 2024 17:51:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> A rename to a typo in preview enum constants missed a usage in tier1 tests. This fixes the typo.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21044#pullrequestreview-2310484262

From liach at openjdk.org  Tue Sep 17 18:17:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 18:17:09 GMT
Subject: RFR: 8340323: Test jdk/classfile/OptionsTest.java fails after
 JDK-8340200
In-Reply-To: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>
References: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>
Message-ID: <Ofu3-exLBxF59aX5_Jt8LlNJXbmxzwDPW6c6xHjbQPE=.d79d0aad-9167-402d-b644-78b657e17167@github.com>

On Tue, 17 Sep 2024 17:51:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> A rename to a typo in preview enum constants missed a usage in tier1 tests. This fixes the typo.

`open/test/jdk/:tier1_part3` confirmed passing, integrating. Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21044#issuecomment-2356593923

From liach at openjdk.org  Tue Sep 17 18:17:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 18:17:09 GMT
Subject: Integrated: 8340323: Test jdk/classfile/OptionsTest.java fails after
 JDK-8340200
In-Reply-To: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>
References: <PgSJ63hLMfuoOlVxpIz522stRKijamaDX6zOtNmEBw8=.710ef2bc-e5f5-497e-bdb3-daf39b55ad01@github.com>
Message-ID: <gNCFldq8aoDTXXqwBP-o8TNIz9m-aEVYW12eQaHV__I=.8b66ec90-d518-4ad9-b690-9a97c7b4efa1@github.com>

On Tue, 17 Sep 2024 17:51:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> A rename to a typo in preview enum constants missed a usage in tier1 tests. This fixes the typo.

This pull request has now been integrated.

Changeset: 5dc9723c
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5dc9723c8172e288872f744bac5fd2342475767a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8340323: Test jdk/classfile/OptionsTest.java fails after JDK-8340200

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21044

From psandoz at openjdk.org  Tue Sep 17 18:24:05 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 18:24:05 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <0LLon0mwzZnp8sR_306z0BoBUjXQAgLBn_KHP-37PC0=.802ff560-b97b-43ba-83b1-94d331d7e03e@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <0LLon0mwzZnp8sR_306z0BoBUjXQAgLBn_KHP-37PC0=.802ff560-b97b-43ba-83b1-94d331d7e03e@github.com>
Message-ID: <fiqKFs5OKldNPyucwmmI8Z60uCvm4h4TA_JpJx5XkEA=.4b63f01b-310a-48b6-b05d-456ef42d89f4@github.com>

On Thu, 22 Aug 2024 18:43:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Adding link to UTF-8 decoding use case for convenience and reminder: https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.

Another related link to base 64 decoding https://github.com/simdutf/SimdBase64/

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2356611024

From dhanalla at openjdk.org  Tue Sep 17 18:33:06 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Tue, 17 Sep 2024 18:33:06 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <tzwuAXVnDvgziQxJHpZPuxd0oCsGXIO1kb8M4vRUttg=.17d6d31d-8532-4615-9e1b-958bee18e75c@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <tzwuAXVnDvgziQxJHpZPuxd0oCsGXIO1kb8M4vRUttg=.17d6d31d-8532-4615-9e1b-958bee18e75c@github.com>
Message-ID: <BM1xZl0lrzbLYOasWiCMvDepPbvM6UvxFudV5b6NThI=.b50b0540-fd6d-4b4b-ad36-6d60310d0eda@github.com>

On Wed, 11 Sep 2024 08:48:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OK thanks, so the change only affects SYSTEM accounts, and such accounts already see a different temp path to non-SYSTEM accounts.
> 
> Newer and older Java versions run by a SYSTEM account will have different temp paths, therefore the hsperfdata_username will be in a different place.
> 
> (I was being picky about attach, but it's a universal thing which is expected to work across different Java versions.)
> 
> Do we have any apps commonly run as a Windows SYSTEM account which expect to attach to other Java apps run by a different Java version? You're suggesting that will have no impact and agreed it would seem really unusual. 8-)

Good Question @kevinjwalls. We are not aware of any customers using attach api tools with Java application of different versions. In these cases, we recommend upgrading to the latest version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2356624922

From bpb at openjdk.org  Tue Sep 17 18:42:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Sep 2024 18:42:12 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
Message-ID: <7O76C4P8PyrxRqlnKSonmckVSIDhAaC3ksa9iwTFe44=.bac91eea-017a-4047-a8f9-40f3509c5eb9@github.com>

On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: "  Doing" -> " Doing" and add some {@code} tags

Review of most recent commit and CSR still needed, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2356640205

From sviswanathan at openjdk.org  Tue Sep 17 18:42:05 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 17 Sep 2024 18:42:05 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <fiqKFs5OKldNPyucwmmI8Z60uCvm4h4TA_JpJx5XkEA=.4b63f01b-310a-48b6-b05d-456ef42d89f4@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <0LLon0mwzZnp8sR_306z0BoBUjXQAgLBn_KHP-37PC0=.802ff560-b97b-43ba-83b1-94d331d7e03e@github.com>
 <fiqKFs5OKldNPyucwmmI8Z60uCvm4h4TA_JpJx5XkEA=.4b63f01b-310a-48b6-b05d-456ef42d89f4@github.com>
Message-ID: <fm2QzLKVlkVTXgDTTMSBdqih1f8nGzMuelF7T6E5ASs=.bf72f7bc-28c0-45ff-8824-33fa1b5292ac@github.com>

On Tue, 17 Sep 2024 18:21:43 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > Adding link to UTF-8 decoding use case for convenience and reminder: https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.
> 
> Another related link to base 64 decoding https://github.com/simdutf/SimdBase64/

Thanks Paul!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2356639277

From duke at openjdk.org  Tue Sep 17 18:55:09 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 17 Sep 2024 18:55:09 GMT
Subject: RFR: 8340200: Misspelled constant
 `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
In-Reply-To: <OIwGedBkGoPsYGqQeh5qeMfxblh9QKGaUd4lAotAhP4=.a1b56410-e240-4c80-b137-c59763e7d263@github.com>
References: <Itq1lX-8kCjdwGgmrtlPBMprM-E5b-w8phqzV7ix4Co=.810e60e6-5f17-470a-8fad-05aacb0cb54a@github.com>
 <OIwGedBkGoPsYGqQeh5qeMfxblh9QKGaUd4lAotAhP4=.a1b56410-e240-4c80-b137-c59763e7d263@github.com>
Message-ID: <mhtViW35o8AVBtIOFedhrX9Gdih-Kz9A_a10iM5zqeQ=.c8fa00b2-d303-4efc-9b0e-70f09a1cc6b6@github.com>

On Tue, 17 Sep 2024 17:31:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks like test/jdk/jdk/classfile/OptionsTest.java was missed.

Ah. I did a code search in the IDE but I forgot that my import doesn't have complete test coverage; I should have grep'd to be sure. Sorry about that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21020#issuecomment-2356662577

From rotanolexandr842 at gmail.com  Tue Sep 17 19:15:31 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Tue, 17 Sep 2024 22:15:31 +0300
Subject: Does API for transformation of class files in Class-FIle API solves
 the same problem as code generationg annotation processors?
Message-ID: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>

Hello there. I am writing to address the overlap between class file
transformation using the ClassFile API and the work done by code-generating
annotation processors, and whether they ultimately solve the same problem.

Annotations such as @Async and @Transactional in popular frameworks are
good examples of code semantics being modified or extended at runtime,
primarily through proxying mechanisms. In these cases, bytecode
transformation is employed under the hood, as the annotations imply
asynchronous execution or transactional boundaries.

The general implication that I am aware of about annotations is that they
can change code semantics. While I am not a fan of this, I can understand
people that once set this rule. And so Class-File API exposing
transformation API for class-files seems like legalizing the bypass of this
rule. I, personally, am a fan of steps in this direction, since I like to
write code generators that generate code for existing classes for fun from
time to time, but that doesnt change my assumption that Class-File API
somehow contradicts general rules applied to annotations by JDK, and it
always seems kind of odd to me when some of API authors speaks so calmly
about on-flight transformations of bytecode while even AST transformations
in compile time aren't supported by JDK.

Moreover, Class-File API seems like more than just an alternative to
generating processors, but rather a weapon of mass destruction compared to
later. Changes to bytecode are always unsafe, and their versatility makes
them much more invasive.

To me, personally, after this API is introduced, addressing long standing
questions of libraries like lombok and more exotic ones like manifold seems
to be an organic step. In my opinion, if even bytecode transformations are
now legal, then much more safe AST transformations (which are safer because
the compiler wont let through invalid AST, while bytecode transformations
could cause silent errors) should also be addressed. SInce JDK historically
mostly focused on code readability, many libraries picked up responsibility
of easing writability, and "legalizing" them, in my opinion, would be a
giant step in the right direction.

So what am I missing here? Or is it really as it seems, that now that
bytecode transformations are in public APIs, making invasive changes in
compiled code is basically legalized? Would really appreciate it if someone
could spare some time to make things clear for me.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240917/c7b3c3eb/attachment.htm>

From ecki at zusammenkunft.net  Tue Sep 17 19:41:19 2024
From: ecki at zusammenkunft.net (Bernd)
Date: Tue, 17 Sep 2024 21:41:19 +0200
Subject: Does API for transformation of class files in Class-FIle API
 solves the same problem as code generationg annotation processors?
In-Reply-To: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>
References: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>
Message-ID: <BAFF454B-DD00-2542-BA93-152753993E0D@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240917/1a98da56/attachment.htm>

From rotanolexandr842 at gmail.com  Tue Sep 17 19:51:38 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Tue, 17 Sep 2024 22:51:38 +0300
Subject: Does API for transformation of class files in Class-FIle API
 solves the same problem as code generationg annotation processors?
In-Reply-To: <BAFF454B-DD00-2542-BA93-152753993E0D@hxcore.ol>
References: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>
 <BAFF454B-DD00-2542-BA93-152753993E0D@hxcore.ol>
Message-ID: <CAL5bRt_ktZeNWBhRU-gyC-p0zB2LdPN31=OqYnP=LaR=8fg0Dw@mail.gmail.com>

When I said that bytecode modification is unsafe, I was mainly
regarding type safety. Compiler does a load of work to not let through
invalid code, and processors that modify ast still have to pass symbol
resolution checks, type checks and many other ones, while
bytecode modification basically has no safety mechanisms other then runtime
failure (and it's good if it fails, there may be just silent errors). In
this sense, I would regard AST modification as much more preferable option
if there was a public API for it

On Tue, Sep 17, 2024 at 10:41?PM Bernd <ecki at zusammenkunft.net> wrote:

> Hello,
>
> To me bytecode is a standardized interface and creating or modifying
> bytecode is legal and not inherently unsafe.
>
> If annotation processor authors want to use bytecode modifications they
> now get an additional tool for that but it doesn?t change the general usage.
>
> In the end users have to know if they want to use intransparent magic like
> Lombok or Pointcuts or even worse runtime agents. And this affects
> selecting platforms who need it or not. (And don?t forget the ecosystem is
> much bigger than Java language alone)
>
> Gru?
> Bernd
> --
> https://bernd.eckenfels.net
>
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Olexandr Rotan <rotanolexandr842 at gmail.com>
> *Sent:* Tuesday, September 17, 2024 9:16 PM
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Does API for transformation of class files in Class-FIle API
> solves the same problem as code generationg annotation processors?
>
> Hello there. I am writing to address the overlap between class file
> transformation using the ClassFile API and the work done by code-generating
> annotation processors, and whether they ultimately solve the same problem.
>
> Annotations such as @Async and @Transactional in popular frameworks are
> good examples of code semantics being modified or extended at runtime,
> primarily through proxying mechanisms. In these cases, bytecode
> transformation is employed under the hood, as the annotations imply
> asynchronous execution or transactional boundaries.
>
> The general implication that I am aware of about annotations is that they
> can change code semantics. While I am not a fan of this, I can understand
> people that once set this rule. And so Class-File API exposing
> transformation API for class-files seems like legalizing the bypass of this
> rule. I, personally, am a fan of steps in this direction, since I like to
> write code generators that generate code for existing classes for fun from
> time to time, but that doesnt change my assumption that Class-File API
> somehow contradicts general rules applied to annotations by JDK, and it
> always seems kind of odd to me when some of API authors speaks so calmly
> about on-flight transformations of bytecode while even AST transformations
> in compile time aren't supported by JDK.
>
> Moreover, Class-File API seems like more than just an alternative to
> generating processors, but rather a weapon of mass destruction compared to
> later. Changes to bytecode are always unsafe, and their versatility makes
> them much more invasive.
>
> To me, personally, after this API is introduced, addressing long standing
> questions of libraries like lombok and more exotic ones like manifold seems
> to be an organic step. In my opinion, if even bytecode transformations are
> now legal, then much more safe AST transformations (which are safer because
> the compiler wont let through invalid AST, while bytecode transformations
> could cause silent errors) should also be addressed. SInce JDK historically
> mostly focused on code readability, many libraries picked up responsibility
> of easing writability, and "legalizing" them, in my opinion, would be a
> giant step in the right direction.
>
> So what am I missing here? Or is it really as it seems, that now that
> bytecode transformations are in public APIs, making invasive changes in
> compiled code is basically legalized? Would really appreciate it if someone
> could spare some time to make things clear for me.
>
> Best regards
>
> --
> https://bernd.eckenfels.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240917/a7d579f6/attachment-0001.htm>

From liach at openjdk.org  Tue Sep 17 21:11:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 21:11:11 GMT
Subject: Integrated: 8340132: Remove internal CpException for reading malformed
 utf8
In-Reply-To: <4b9JSdqSCVew2frracl6hRTFgNkhsddNM-HspAaKnYI=.362ac9e2-5453-4a65-87c8-6ad1c0d77a53@github.com>
References: <4b9JSdqSCVew2frracl6hRTFgNkhsddNM-HspAaKnYI=.362ac9e2-5453-4a65-87c8-6ad1c0d77a53@github.com>
Message-ID: <ZBLwb03CKsY8aPfshgaZHX8_Z1G6w3d3mhn6_ELz3wY=.bc9c0e00-1170-471d-b672-8aa2479f01b1@github.com>

On Tue, 17 Sep 2024 03:24:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove an internal exception for invalid utf8 entry format; it should have been an IllegalArgumentException but was an arbitrary subtype of RuntimeException. Converted to throw ConstantPoolException, and consolidated into a single method to reduce code size.

This pull request has now been integrated.

Changeset: dfc90938
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfc90938ba36685ef58af0846ee4bdb214fa210f
Stats:     17 lines in 1 file changed: 4 ins; 8 del; 5 mod

8340132: Remove internal CpException for reading malformed utf8

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/21027

From redestad at openjdk.org  Tue Sep 17 22:28:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Sep 2024 22:28:17 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms [v2]
In-Reply-To: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
Message-ID: <QtI7BIl80eAKhxqFnOwP_98fJ2qjL_IlehxQOOF2A6A=.9b32830e-e692-42a1-aece-8f7b52145257@github.com>

> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
> 
> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
> 
> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove argumentsWithTrailingObjectArguments (only one use), handle the logic at callsite

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21035/files
  - new: https://git.openjdk.org/jdk/pull/21035/files/657f490e..3231f967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21035&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21035&range=00-01

  Stats: 26 lines in 3 files changed: 7 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21035/head:pull/21035

PR: https://git.openjdk.org/jdk/pull/21035

From liach at openjdk.org  Tue Sep 17 22:37:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 22:37:05 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms [v2]
In-Reply-To: <QtI7BIl80eAKhxqFnOwP_98fJ2qjL_IlehxQOOF2A6A=.9b32830e-e692-42a1-aece-8f7b52145257@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
 <QtI7BIl80eAKhxqFnOwP_98fJ2qjL_IlehxQOOF2A6A=.9b32830e-e692-42a1-aece-8f7b52145257@github.com>
Message-ID: <1Cjh3DIFqikMEY88hGXAk_8TY7r2AOav1-BA7Sv9d7s=.d4694bfd-0a95-4a0b-8ec1-6f2d4238535b@github.com>

On Tue, 17 Sep 2024 22:28:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
>> 
>> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
>> 
>> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove argumentsWithTrailingObjectArguments (only one use), handle the logic at callsite

src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 256:

> 254:         if (doesAlloc) {
> 255:             var ptypes = mtype.ptypes();
> 256:             var newPtypes = new Class<?>[ptypes.length + (doesAlloc ? 2 : 1)];

Suggestion:

            var newPtypes = new Class<?>[ptypes.length + 2];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21035#discussion_r1764097518

From redestad at openjdk.org  Tue Sep 17 22:40:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Sep 2024 22:40:34 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms [v3]
In-Reply-To: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
Message-ID: <TZQ1rmcGxdfj327JR5qOk6HdTs0JaFBqV9WLtqzidXc=.8c50f7b3-9e13-4d39-9b61-5057effccad2@github.com>

> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
> 
> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
> 
> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21035/files
  - new: https://git.openjdk.org/jdk/pull/21035/files/3231f967..9dba8eb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21035&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21035&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21035/head:pull/21035

PR: https://git.openjdk.org/jdk/pull/21035

From liach at openjdk.org  Tue Sep 17 22:47:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 22:47:06 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms [v3]
In-Reply-To: <TZQ1rmcGxdfj327JR5qOk6HdTs0JaFBqV9WLtqzidXc=.8c50f7b3-9e13-4d39-9b61-5057effccad2@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
 <TZQ1rmcGxdfj327JR5qOk6HdTs0JaFBqV9WLtqzidXc=.8c50f7b3-9e13-4d39-9b61-5057effccad2@github.com>
Message-ID: <ri7DSEhv6RA9xOwttHBh0TZAH0WEWDcVyDEU0cMD6iE=.8aaf1af9-035d-49c6-a17a-774714293dd5@github.com>

On Tue, 17 Sep 2024 22:40:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
>> 
>> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
>> 
>> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21035#pullrequestreview-2311215143

From rotanolexandr842 at gmail.com  Tue Sep 17 22:49:04 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 18 Sep 2024 01:49:04 +0300
Subject: Does API for transformation of class files in Class-FIle API
 solves the same problem as code generationg annotation processors?
In-Reply-To: <CAL5bRt_ktZeNWBhRU-gyC-p0zB2LdPN31=OqYnP=LaR=8fg0Dw@mail.gmail.com>
References: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>
 <BAFF454B-DD00-2542-BA93-152753993E0D@hxcore.ol>
 <CAL5bRt_ktZeNWBhRU-gyC-p0zB2LdPN31=OqYnP=LaR=8fg0Dw@mail.gmail.com>
Message-ID: <CAL5bRt8H2yaMcchApG=3WehisH0GcNM6q7bE1Y=8auG8tubcjQ@mail.gmail.com>

Sorry for followup letter, just mentioned that I wrote that annotations CAN
change the semantics, while I meant CANNOT. With this typo letter makes
little to none sense, so correction is important

On Tue, Sep 17, 2024, 22:51 Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> When I said that bytecode modification is unsafe, I was mainly
> regarding type safety. Compiler does a load of work to not let through
> invalid code, and processors that modify ast still have to pass symbol
> resolution checks, type checks and many other ones, while
> bytecode modification basically has no safety mechanisms other then runtime
> failure (and it's good if it fails, there may be just silent errors). In
> this sense, I would regard AST modification as much more preferable option
> if there was a public API for it
>
> On Tue, Sep 17, 2024 at 10:41?PM Bernd <ecki at zusammenkunft.net> wrote:
>
>> Hello,
>>
>> To me bytecode is a standardized interface and creating or modifying
>> bytecode is legal and not inherently unsafe.
>>
>> If annotation processor authors want to use bytecode modifications they
>> now get an additional tool for that but it doesn?t change the general usage.
>>
>> In the end users have to know if they want to use intransparent magic
>> like Lombok or Pointcuts or even worse runtime agents. And this affects
>> selecting platforms who need it or not. (And don?t forget the ecosystem is
>> much bigger than Java language alone)
>>
>> Gru?
>> Bernd
>> --
>> https://bernd.eckenfels.net
>>
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
>> Olexandr Rotan <rotanolexandr842 at gmail.com>
>> *Sent:* Tuesday, September 17, 2024 9:16 PM
>> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Does API for transformation of class files in Class-FIle API
>> solves the same problem as code generationg annotation processors?
>>
>> Hello there. I am writing to address the overlap between class file
>> transformation using the ClassFile API and the work done by code-generating
>> annotation processors, and whether they ultimately solve the same problem.
>>
>> Annotations such as @Async and @Transactional in popular frameworks are
>> good examples of code semantics being modified or extended at runtime,
>> primarily through proxying mechanisms. In these cases, bytecode
>> transformation is employed under the hood, as the annotations imply
>> asynchronous execution or transactional boundaries.
>>
>> The general implication that I am aware of about annotations is that they
>> can change code semantics. While I am not a fan of this, I can understand
>> people that once set this rule. And so Class-File API exposing
>> transformation API for class-files seems like legalizing the bypass of this
>> rule. I, personally, am a fan of steps in this direction, since I like to
>> write code generators that generate code for existing classes for fun from
>> time to time, but that doesnt change my assumption that Class-File API
>> somehow contradicts general rules applied to annotations by JDK, and it
>> always seems kind of odd to me when some of API authors speaks so calmly
>> about on-flight transformations of bytecode while even AST transformations
>> in compile time aren't supported by JDK.
>>
>> Moreover, Class-File API seems like more than just an alternative to
>> generating processors, but rather a weapon of mass destruction compared to
>> later. Changes to bytecode are always unsafe, and their versatility makes
>> them much more invasive.
>>
>> To me, personally, after this API is introduced, addressing long standing
>> questions of libraries like lombok and more exotic ones like manifold seems
>> to be an organic step. In my opinion, if even bytecode transformations are
>> now legal, then much more safe AST transformations (which are safer because
>> the compiler wont let through invalid AST, while bytecode transformations
>> could cause silent errors) should also be addressed. SInce JDK historically
>> mostly focused on code readability, many libraries picked up responsibility
>> of easing writability, and "legalizing" them, in my opinion, would be a
>> giant step in the right direction.
>>
>> So what am I missing here? Or is it really as it seems, that now that
>> bytecode transformations are in public APIs, making invasive changes in
>> compiled code is basically legalized? Would really appreciate it if someone
>> could spare some time to make things clear for me.
>>
>> Best regards
>>
>> --
>> https://bernd.eckenfels.net
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240918/6203def7/attachment.htm>

From chen.l.liang at oracle.com  Tue Sep 17 23:02:17 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 17 Sep 2024 23:02:17 +0000
Subject: Does API for transformation of class files in Class-FIle API
 solves the same problem as code generationg annotation processors?
In-Reply-To: <CAL5bRt8H2yaMcchApG=3WehisH0GcNM6q7bE1Y=8auG8tubcjQ@mail.gmail.com>
References: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>
 <BAFF454B-DD00-2542-BA93-152753993E0D@hxcore.ol>
 <CAL5bRt_ktZeNWBhRU-gyC-p0zB2LdPN31=OqYnP=LaR=8fg0Dw@mail.gmail.com>
 <CAL5bRt8H2yaMcchApG=3WehisH0GcNM6q7bE1Y=8auG8tubcjQ@mail.gmail.com>
Message-ID: <SJ2PR10MB76699BA4A5C3CAECDF5FC970A2612@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Olex,
ClassFile API provides a general-purpose API to interact with byte data for the class file format. It does not control, nor can it control, where the byte data comes from or where the byte data goes. So, the API doesn't know if you are upgrading old formats, such as migrating to value classes or removing jsr instructions, or constant-folding expressions to dynamic constants, or to add dangerous hacks to the class file. And there is no way to control it for the API. The only way you can safeguard is to ensure you disable dynamic agents and use libraries that you trust. Our current recommendation is to use ClassFile API to pre-process (similar to annotation processing in compilation), such as putting all candidate classes in a flat directory; run-time bytecode loading (such as minecraft mods) is much harder to optimize (such as for Leyden) and difficult to detect errors.

If you consider bytecode modification unsafe, you can use ClassFile::verify to ensure your generated bytecode passes verification. This is not a prerequisite to bytecode generation as this process is quite slow, but you can always run it in your program or toggle it with a property. StackMapTable attribute is quite a good tool to ensure the type safety within Java's class file format.

For semantic change: Annotation processors change the semantics of the language and start from an invalid language semantic; meanwhile, classfile transformation start valid and end with a valid class file format. I think this is the principal difference here.

Regards, Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Olexandr Rotan <rotanolexandr842 at gmail.com>
Sent: Tuesday, September 17, 2024 5:49 PM
To: Bernd <ecki at zusammenkunft.net>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?


Sorry for followup letter, just mentioned that I wrote that annotations CAN change the semantics, while I meant CANNOT. With this typo letter makes little to none sense, so correction is important

On Tue, Sep 17, 2024, 22:51 Olexandr Rotan <rotanolexandr842 at gmail.com<mailto:rotanolexandr842 at gmail.com>> wrote:
When I said that bytecode modification is unsafe, I was mainly regarding type safety. Compiler does a load of work to not let through invalid code, and processors that modify ast still have to pass symbol resolution checks, type checks and many other ones, while bytecode modification basically has no safety mechanisms other then runtime failure (and it's good if it fails, there may be just silent errors). In this sense, I would regard AST modification as much more preferable option if there was a public API for it

On Tue, Sep 17, 2024 at 10:41?PM Bernd <ecki at zusammenkunft.net<mailto:ecki at zusammenkunft.net>> wrote:
Hello,

To me bytecode is a standardized interface and creating or modifying bytecode is legal and not inherently unsafe.

If annotation processor authors want to use bytecode modifications they now get an additional tool for that but it doesn?t change the general usage.

In the end users have to know if they want to use intransparent magic like Lombok or Pointcuts or even worse runtime agents. And this affects selecting platforms who need it or not. (And don?t forget the ecosystem is much bigger than Java language alone)

Gru?
Bernd
--
https://bernd.eckenfels.net

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Olexandr Rotan <rotanolexandr842 at gmail.com<mailto:rotanolexandr842 at gmail.com>>
Sent: Tuesday, September 17, 2024 9:16 PM
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: Does API for transformation of class files in Class-FIle API solves the same problem as code generationg annotation processors?

Hello there. I am writing to address the overlap between class file transformation using the ClassFile API and the work done by code-generating annotation processors, and whether they ultimately solve the same problem.

Annotations such as @Async and @Transactional in popular frameworks are good examples of code semantics being modified or extended at runtime, primarily through proxying mechanisms. In these cases, bytecode transformation is employed under the hood, as the annotations imply asynchronous execution or transactional boundaries.

The general implication that I am aware of about annotations is that they can change code semantics. While I am not a fan of this, I can understand people that once set this rule. And so Class-File API exposing transformation API for class-files seems like legalizing the bypass of this rule. I, personally, am a fan of steps in this direction, since I like to write code generators that generate code for existing classes for fun from time to time, but that doesnt change my assumption that Class-File API somehow contradicts general rules applied to annotations by JDK, and it always seems kind of odd to me when some of API authors speaks so calmly about on-flight transformations of bytecode while even AST transformations in compile time aren't supported by JDK.

Moreover, Class-File API seems like more than just an alternative to generating processors, but rather a weapon of mass destruction compared to later. Changes to bytecode are always unsafe, and their versatility makes them much more invasive.

To me, personally, after this API is introduced, addressing long standing questions of libraries like lombok and more exotic ones like manifold seems to be an organic step. In my opinion, if even bytecode transformations are now legal, then much more safe AST transformations (which are safer because the compiler wont let through invalid AST, while bytecode transformations could cause silent errors) should also be addressed. SInce JDK historically mostly focused on code readability, many libraries picked up responsibility of easing writability, and "legalizing" them, in my opinion, would be a giant step in the right direction.

So what am I missing here? Or is it really as it seems, that now that bytecode transformations are in public APIs, making invasive changes in compiled code is basically legalized? Would really appreciate it if someone could spare some time to make things clear for me.

Best regards

--
https://bernd.eckenfels.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240917/74ac8d61/attachment-0001.htm>

From jlu at openjdk.org  Tue Sep 17 23:20:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Sep 2024 23:20:35 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs
Message-ID: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>

Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.

Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
This change does not include removal of usages in a historical sense. For example, something such as 


 * @apiNote
 * Thread groups provided a way in early Java releases to group threads and provide
 * a form of <i>job control</i> for threads. Thread groups supported the isolation
 * of applets and defined methods intended for diagnostic purposes. It should be
 * rare for new applications to create ThreadGroups and interact with this API.


in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21046/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339735
  Stats: 17 lines in 7 files changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21046/head:pull/21046

PR: https://git.openjdk.org/jdk/pull/21046

From naoto at openjdk.org  Tue Sep 17 23:50:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Sep 2024 23:50:06 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:

> 72: <code>volatile</code> (or access to the variable must be
> 73: synchronized).</p>
> 74: <p>For example, suppose your application contains the following

The example below is still applet specific (e.g., `repaint()`). May need to be more generic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764214361

From ccheung at openjdk.org  Tue Sep 17 23:50:19 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 17 Sep 2024 23:50:19 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time
Message-ID: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>

Prior to this patch, if `--module-path` is specified in the command line:
during CDS dump time, full module graph will not be included in the CDS archive;
during run time, full module graph will not be used.

With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.

The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
E.g. the following is considered a match:
dump time      runtime
m1,m2             m2,m1
m1,m2             m1,m2,m2

I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

-------------

Commit messages:
 - 8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time

Changes: https://git.openjdk.org/jdk/pull/21048/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328313
  Stats: 460 lines in 17 files changed: 420 ins; 2 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From iklam at openjdk.org  Tue Sep 17 23:57:15 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Sep 2024 23:57:15 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache
Message-ID: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>

This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).

The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.

However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.

The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.

[JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.

This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).

---
See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

-------------

Depends on: https://git.openjdk.org/jdk/pull/20959

Commit messages:
 - Do not use system property to limit usage to only CDS static dumps
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

Changes: https://git.openjdk.org/jdk/pull/21049/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311071
  Stats: 72 lines in 4 files changed: 46 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From dholmes at openjdk.org  Wed Sep 18 01:05:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Sep 2024 01:05:15 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <qgP0Lc-HA6waUZ_9dQjS6Nxk3ljWZnDl8dVrp5A8uac=.1cc3b1a1-c5da-408f-ad47-60b137a1db56@github.com>

On Tue, 17 Sep 2024 23:48:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

This seems quite reasonable for dumping the static archive.

A couple of typos.

Thanks

src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 62:

> 60:     static final boolean PROFILE_GWT;
> 61:     static final int CUSTOMIZE_THRESHOLD;
> 62:     static final boolean NO_SOFT_CACHE; // Don't use SoftReference in LambdaFormEditor and MethodTypeForm so they can archived by CDS.

Suggestion:

    static final boolean NO_SOFT_CACHE; // Don't use SoftReference in LambdaFormEditor and MethodTypeForm so they can be archived by CDS.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 81:

> 79:     /*
> 80:      * Wwhen dumping the static archive, CDS is able to archive MethodHandles.
> 81:      * However, CDS cannot archive SoftReferences objects, so we need to

Suggestion:

     * However, CDS cannot archive SoftReference objects, so we need to

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2311403651
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764251342
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764253505

From dholmes at openjdk.org  Wed Sep 18 01:37:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Sep 2024 01:37:04 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <8QVb7SLhVWE1Q0U7_2oOpcltcNbKEYw4PJ1zi01U-tc=.207e30c8-4c9b-40da-a3a5-9389c4fcc44b@github.com>

On Tue, 17 Sep 2024 23:44:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

I've taken an initial pass through and this seems reasonable (a bit more complicated than the description suggested :) ).

Thanks

src/hotspot/share/cds/filemap.cpp line 931:

> 929: bool FileMapInfo::is_jar_suffix(const char* filename) {
> 930:   const char* dot = strrchr(filename, '.');
> 931:   if (strcmp(dot + 1, "jar") == 0) {

What if there is no dot? We need a null check.

src/hotspot/share/cds/filemap.hpp line 558:

> 556:                     unsigned int dumptime_prefix_len,
> 557:                     unsigned int runtime_prefix_len) NOT_CDS_RETURN_(false);
> 558:   bool  is_jar_suffix(const char* filename);

Suggestion: has_jar_suffix

src/hotspot/share/cds/heapShared.cpp line 884:

> 882:       ClassLoaderExt::num_module_paths() > 0) {
> 883:     log_info(cds, heap)("    is_using_optimized_module_handling %d num_module_paths %d jdk.module.main %s",
> 884:         CDSConfig::is_using_optimized_module_handling(), ClassLoaderExt::num_module_paths(), Arguments::get_property("jdk.module.main"));

Why are you printing a bool value as an int? I'm surprised one of the format checkers doesn't complain about it.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2311418590
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1764261758
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1764267214
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1764268462

From iklam at openjdk.org  Wed Sep 18 01:53:42 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 18 Sep 2024 01:53:42 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v2]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <F0EH6GOREKPIbO6J9BIL2rKdj7EsHKTi9rb8WRS08No=.b48cb06b-bd91-4a93-81c7-e76315c88826@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Do not use system property to limit usage to only CDS static dumps
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/867e4434..db87b246

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=00-01

  Stats: 224 lines in 10 files changed: 97 ins; 74 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From iklam at openjdk.org  Wed Sep 18 03:04:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 18 Sep 2024 03:04:50 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v3]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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:

 - @dholmes-ora review comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Do not use system property to limit usage to only CDS static dumps
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/db87b246..76ef3b33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=01-02

  Stats: 12 lines in 3 files changed: 5 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From dholmes at openjdk.org  Wed Sep 18 04:15:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Sep 2024 04:15:06 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v7]
In-Reply-To: <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
Message-ID: <AcZhT9rB8mQ_KJozReBrDRUBuDERcTO07p4cAqqY6ds=.9fa18100-17ef-4a71-a702-860b5039b669@github.com>

On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treat -version: -jre-restrict-search and -jre-no-restrict-search like any other unknown option

Great to see this further simplification.

I agree no CSR request needed as all that happens is the error message changes.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20997#pullrequestreview-2311571248

From darcy at openjdk.org  Wed Sep 18 04:39:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Sep 2024 04:39:04 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v7]
In-Reply-To: <AcZhT9rB8mQ_KJozReBrDRUBuDERcTO07p4cAqqY6ds=.9fa18100-17ef-4a71-a702-860b5039b669@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
 <AcZhT9rB8mQ_KJozReBrDRUBuDERcTO07p4cAqqY6ds=.9fa18100-17ef-4a71-a702-860b5039b669@github.com>
Message-ID: <G24HzFT23E_qDryrzJ-FWcIC7a2tnAC_sVgWM7QY38I=.f9bf175c-7551-4825-9487-e80a562c9fb4@github.com>

On Wed, 18 Sep 2024 04:12:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Great to see this further simplification.
> 
> I agree no CSR request needed as all that happens is the error message changes.
> 
> Thanks

I agree no CSR is needed. Having worked on the launcher many years back, including adding the original flow chart diagram pre-OpenJDK, I'm happy to see resumed efforts here :-)

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20997#issuecomment-2357477127

From dholmes at openjdk.org  Wed Sep 18 04:42:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Sep 2024 04:42:05 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v3]
In-Reply-To: <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
Message-ID: <Qb-HD7Ls-A8bMX1qp1DXVNLp-8m4N67AAQgxEcrzh0s=.3d1b0e33-7a00-49eb-8ed4-9c101524a1f4@github.com>

On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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:
> 
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2311592121

From liach at openjdk.org  Wed Sep 18 05:22:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 18 Sep 2024 05:22:06 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v3]
In-Reply-To: <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
Message-ID: <c35ig7Etq0YOUxeTlbBu6w-rUHSK3rCavYuP4UzgKl8=.20881d2e-446a-4fe1-8eb3-2fd5c37facee@github.com>

On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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:
> 
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 148:

> 146:         public LambdaForm get() {
> 147:             if (cache instanceof LambdaForm) {
> 148:                 return (LambdaForm)cache;

Suggestion:

            if (cache instanceof LambdaForm lf) {
                return lf;

src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 119:

> 117:             return null;
> 118:         } else if (entry instanceof MethodHandle) {
> 119:             return (MethodHandle) entry;

Suggestion:

        } else if (entry instanceof MethodHandle mh) {
            return mh;

src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 145:

> 143:             return null;
> 144:         } else if (entry instanceof LambdaForm) {
> 145:             return (LambdaForm) entry;

Suggestion:

        } else if (entry instanceof LambdaForm lf) {
            return lf;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764400587
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764400920
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764401134

From jpai at openjdk.org  Wed Sep 18 05:57:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Sep 2024 05:57:08 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
Message-ID: <7bAlcZ3zTDLnSZmeTJaYdGY6skXLV7S77CkIR2Y3l2c=.a78fa91b-0408-42ed-abb2-45b76cbe2253@github.com>

On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: "  Doing" -> " Doing" and add some {@code} tags

Sorry Brian, I forgot to check the CSR. The current state of this PR looks good to me. I'll review the CSR too.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20320#pullrequestreview-2311688356

From coffeys at openjdk.org  Wed Sep 18 06:28:05 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Sep 2024 06:28:05 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
Message-ID: <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>

On Tue, 17 Sep 2024 23:36:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:
> 
>> 72: <code>volatile</code> (or access to the variable must be
>> 73: synchronized).</p>
>> 74: <p>For example, suppose your application contains the following
> 
> The example below is still applet specific (e.g., `repaint()`). May need to be more generic.

`repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.

given the thread name `blink`, perhaps we could just use `blink()` in this example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764469513

From duke at openjdk.org  Wed Sep 18 06:43:07 2024
From: duke at openjdk.org (duke)
Date: Wed, 18 Sep 2024 06:43:07 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v5]
In-Reply-To: <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <ESSM4vXAdlZK_hFRKki__NO-fQ0-qoS_TNwqHR1zQWY=.976d4b89-ecba-43fb-8834-1527165d4fe7@github.com>
Message-ID: <cVTe1pq6JoxsCnASHtHCXJXzJdEK7AzQQTDsnPlAsnE=.08130ad8-499f-4db8-add9-d86a86469d5b@github.com>

On Tue, 17 Sep 2024 15:23:41 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Add comment with class that is created.

@raphw 
Your change (at version e951362736a8156d719a083c875f1564ac7f8827) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20535#issuecomment-2357628491

From alanb at openjdk.org  Wed Sep 18 06:56:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Sep 2024 06:56:07 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <jji2cBznsQxB3R4AhXAcrpB4VjoBZM9FnHvPm1W23mI=.455655bc-617a-48c4-bb48-59c6d111d48d@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39:

> 37:  * implementation classes.  Charset providers may be installed in an instance
> 38:  * of the Java platform as extensions.  Providers may also be made available by
> 39:  * adding them to the application class path or by some other

They can also be deployed on the application module path, maybe need a separate JBS issue to clarify that part of the spec, and add a test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764498846

From alanb at openjdk.org  Wed Sep 18 06:56:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Sep 2024 06:56:06 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
 <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>
Message-ID: <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com>

On Wed, 18 Sep 2024 06:25:57 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:
>> 
>>> 72: <code>volatile</code> (or access to the variable must be
>>> 73: synchronized).</p>
>>> 74: <p>For example, suppose your application contains the following
>> 
>> The example below is still applet specific (e.g., `repaint()`). May need to be more generic.
>
> `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.
> 
> given the thread name `blink`, perhaps we could just use `blink()` in this example.

Don't waste too much time on the "Java Thread Primitive Deprecation" page. The last remnant is the no-arg Thread.stop method which throws UOE unconditionally. Once that is removed then the doc-file pages will be removed too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764497660

From redestad at openjdk.org  Wed Sep 18 07:04:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Sep 2024 07:04:22 GMT
Subject: RFR: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms [v3]
In-Reply-To: <TZQ1rmcGxdfj327JR5qOk6HdTs0JaFBqV9WLtqzidXc=.8c50f7b3-9e13-4d39-9b61-5057effccad2@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
 <TZQ1rmcGxdfj327JR5qOk6HdTs0JaFBqV9WLtqzidXc=.8c50f7b3-9e13-4d39-9b61-5057effccad2@github.com>
Message-ID: <pRKR-yorYcENtynUwA2mhBGZZxqVvEyoZp5EjgbVGN8=.6fe7f44b-ae9a-4f47-a04e-88346b8ace7c@github.com>

On Tue, 17 Sep 2024 22:40:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
>> 
>> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
>> 
>> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21035#issuecomment-2357659070

From redestad at openjdk.org  Wed Sep 18 07:04:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Sep 2024 07:04:22 GMT
Subject: Integrated: 8340280: Avoid calling MT.invokerType() when creating
 LambdaForms
In-Reply-To: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
References: <sHmrbR_gYvL_7LyWQcajXgfRgl94ZunVkQ08E9PXiz0=.f1c744ef-c059-443a-b3ee-5f0400e742bc@github.com>
Message-ID: <38j6YCsFQK6CblzBkS32HBnAYaWKLFkGPGhUM8Sbx-A=.eba5f139-b7e3-4579-af38-dc919d0b7542@github.com>

On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR exploits the observation that in many of the cases where we call `methodType.invokerType()` we immediately translate it into a `Name[]` where the only effect is to create an array with an additional leading `BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding `invokerType()` be created later to bind the MH to an invoker.
> 
> Providing methods to bypass the creationg of such transient, intermediary `MethodType` creation avoids excessive allocations and adding types to the MT interning table that quickly become stale.
> 
> Number of executed bytecode on a trivial HelloLambda application drops locally from ~517k to ~505k.

This pull request has now been integrated.

Changeset: d23c59e4
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d23c59e40812c9e3a5914193e68169dbdf6d09e5
Stats:     60 lines in 6 files changed: 17 ins; 12 del; 31 mod

8340280: Avoid calling MT.invokerType() when creating LambdaForms

Reviewed-by: liach, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21035

From jbhateja at openjdk.org  Wed Sep 18 07:21:52 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 07:21:52 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v12]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <YTuwAMwWzDUteOb6zkIIPfoVp2IBCU2BLjJGMdN1q20=.a0cb7d5f-6ec3-4cca-9c2c-6439cee6180c@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Incorporating review and documentation suggestions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/29530047..31a58642

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=10-11

  Stats: 96 lines in 8 files changed: 25 ins; 0 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Wed Sep 18 07:21:52 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 07:21:52 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <SYac8lqYykI_Clh7VMxU4dh3mrW1aEBCLidCqo0MTjo=.7aa5a12c-4eef-46d0-8112-20057e715215@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <7bghGF2-qbhP1hJA2ljtdA3xSUSqiV0RLaOYm4AcZSQ=.eb3e36b2-5461-4755-ae71-2de89660649f@github.com>
 <SYac8lqYykI_Clh7VMxU4dh3mrW1aEBCLidCqo0MTjo=.7aa5a12c-4eef-46d0-8112-20057e715215@github.com>
Message-ID: <wI1qpqX6kM_WV1zMP6wB4848YbkT7GCQ4FJYDtEqxWs=.27bedc2c-bd49-4937-b3f1-ccdbbb25594e@github.com>

On Fri, 13 Sep 2024 14:49:01 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 544:
>> 
>>> 542:         byte[] vpayload1 = ((ByteVector)v1).vec();
>>> 543:         byte[] vpayload2 = ((ByteVector)v2).vec();
>>> 544:         byte[] vpayload3 = ((ByteVector)v3).vec();
>> 
>> Is there a reason you are not using more descriptive names here instead of `vpayload1`?
>> I also wonder if the `selectFromHelper` should not be named more specifically: `selectFromTwoVector(s)Helper`?
>
> You only gave me a thumbs up and no change - but comment resolved. Is that intentional? Makes me feel like you are ignoring my comments, and that discourages me from reviewing in the future.

Routine was renamed as per you suggestion and first vector argument also appropriately renamed to wrappedIndex.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1764527888

From amitkumar at openjdk.org  Wed Sep 18 09:15:05 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 18 Sep 2024 09:15:05 GMT
Subject: RFR: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
In-Reply-To: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
References: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
Message-ID: <FCpG0wJWEMPKva43HUXr4Q_mBiRMG0WdJ1Y44xVzQIM=.fbb709e2-c07f-406b-b267-a24e80bd3593@github.com>

On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).

@RealLucy can you have a quick look at this one ? It's trivial change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20960#issuecomment-2357924193

From rotanolexandr842 at gmail.com  Wed Sep 18 10:26:51 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 18 Sep 2024 13:26:51 +0300
Subject: Does API for transformation of class files in Class-FIle API
 solves the same problem as code generationg annotation processors?
In-Reply-To: <SJ2PR10MB76699BA4A5C3CAECDF5FC970A2612@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAL5bRt_YmcE5w3DHCYVB7xeLVRGQcrNNkA09B3mr14UtNjQ2VQ@mail.gmail.com>
 <BAFF454B-DD00-2542-BA93-152753993E0D@hxcore.ol>
 <CAL5bRt_ktZeNWBhRU-gyC-p0zB2LdPN31=OqYnP=LaR=8fg0Dw@mail.gmail.com>
 <CAL5bRt8H2yaMcchApG=3WehisH0GcNM6q7bE1Y=8auG8tubcjQ@mail.gmail.com>
 <SJ2PR10MB76699BA4A5C3CAECDF5FC970A2612@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAL5bRt9d=crWLb3oEyxDVouP7TjC_9NGwh6XUn5cBX_7O60wMA@mail.gmail.com>

>
> It does not control, nor can it control, where the byte data comes from or
> where the byte data goes.


That's true. Although, why I am saying that one of the Class-File API goals
is to allow semantic modifications, is because the authors of API
specifically said that when asked about use cases. The talk that
particularly motivated me to write the letter was Brian Goetz talk on Java
23 launch stream, where he said something along the lines "add a few
bytecodes at the start of the method". So this is not an uncontrollable
side effect, but rather an intentional way to use API.

If you consider bytecode modification unsafe, you can use ClassFile::verify
> to ensure your generated bytecode passes verification.


I am not that familiar with API, but I'm sure it has its limits. I'm sure
it is capable of verifying classfiel structure, but I highly doubt that it
can enforce things like type safety, especially with generics, verifying
pointers to symbols are correct etc. WOuld be glad to be mistaken though.

For semantic change: Annotation processors change the semantics of the
> language and start from an invalid language semantic; meanwhile, classfile
> transformation start valid and end with a valid class file format. I think
> this is the principal difference here.


That is true if the assumption that annotations can't change semantics of
code like keywords do. That`s why I am wondering if it still stays the
same, since class-file api seems to legalize these changes. Yes, class
files are valid on start and valid in the end, but that doesn't change the
fact that semantics is changed. Moreover, some annotation processors also
start with valid semantics and end with valid one, let's say
lombok`s @Locked, @EqualsAndHashCode etc. Other annotations like @Getter
and @Setter are not more "illegal" at the start than any processor that
generates additional classes, since symbols are unresolved in both of these
cases. Annotation processors are still obliged to pass syntax checks, they
can't invent new language constructs, keywords or statements. So the
annotation processor is not obliged to start with invalid semantics.
Moreover, if annotations are now effectively allowed to change code
semantics, then the "code semantics" itself could be stretched
indefinitely. If annotation of type guarantees presence of method,
developers knows about it, and annotation is allowed to alter type`s
members list, then semantics seems pretty valid to me, at least as valid as
if we were to refer to some annotations like mapstruct`s @Mapper, which is
completely build on public APIs. Having all that, I, personally, don't see
how processors are more harmful then bytecode transformations.

>From now on, this is just my thoughts on annotation processing in the
ecosystem.

I, personally, don't see any particular harm in processors like Lombok,
that are used to eliminate boilerplate code. Anyone who ever wrote code
using it knows that it dramatically enhances both writability and
readability of code. I think the fact that lombok is even present in spring
boot starters speaks to the popularity of the library a lot. Of course,
there are much more invasive ones, that I am not a fan of honestly.
Although, what I think, is that if there were some "legal" extent to which
annotation processors could invade in existing code, say wrapping method
bodies and generating new members for existing types and a few others,
which would cover 99% of sane use cases, this would encourage people to use
and write "sane" annotation processors that are proven to improve
productivity and discourage use of "crazy" ones due to stability of premier
ones.

On Wed, Sep 18, 2024 at 2:02?AM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Olex,
> ClassFile API provides a general-purpose API to interact with byte data
> for the class file format. It does not control, nor can it control, where
> the byte data comes from or where the byte data goes. So, the API doesn't
> know if you are upgrading old formats, such as migrating to value classes
> or removing jsr instructions, or constant-folding expressions to dynamic
> constants, or to add dangerous hacks to the class file. And there is no way
> to control it for the API. The only way you can safeguard is to ensure you
> disable dynamic agents and use libraries that you trust. Our current
> recommendation is to use ClassFile API to pre-process (similar to
> annotation processing in compilation), such as putting all candidate
> classes in a flat directory; run-time bytecode loading (such as minecraft
> mods) is much harder to optimize (such as for Leyden) and difficult to
> detect errors.
>
> If you consider bytecode modification unsafe, you can use
> ClassFile::verify to ensure your generated bytecode passes verification.
> This is not a prerequisite to bytecode generation as this process is quite
> slow, but you can always run it in your program or toggle it with a
> property. StackMapTable attribute is quite a good tool to ensure the type
> safety within Java's class file format.
>
> For semantic change: Annotation processors change the semantics of the
> language and start from an invalid language semantic; meanwhile, classfile
> transformation start valid and end with a valid class file format. I think
> this is the principal difference here.
>
> Regards, Chen
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Olexandr Rotan <rotanolexandr842 at gmail.com>
> *Sent:* Tuesday, September 17, 2024 5:49 PM
> *To:* Bernd <ecki at zusammenkunft.net>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: Does API for transformation of class files in Class-FIle
> API solves the same problem as code generationg annotation processors?
>
>
> Sorry for followup letter, just mentioned that I wrote that annotations
> CAN change the semantics, while I meant CANNOT. With this typo letter makes
> little to none sense, so correction is important
>
> On Tue, Sep 17, 2024, 22:51 Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
> When I said that bytecode modification is unsafe, I was mainly
> regarding type safety. Compiler does a load of work to not let through
> invalid code, and processors that modify ast still have to pass symbol
> resolution checks, type checks and many other ones, while
> bytecode modification basically has no safety mechanisms other then runtime
> failure (and it's good if it fails, there may be just silent errors). In
> this sense, I would regard AST modification as much more preferable option
> if there was a public API for it
>
> On Tue, Sep 17, 2024 at 10:41?PM Bernd <ecki at zusammenkunft.net> wrote:
>
> Hello,
>
> To me bytecode is a standardized interface and creating or modifying
> bytecode is legal and not inherently unsafe.
>
> If annotation processor authors want to use bytecode modifications they
> now get an additional tool for that but it doesn?t change the general usage.
>
> In the end users have to know if they want to use intransparent magic like
> Lombok or Pointcuts or even worse runtime agents. And this affects
> selecting platforms who need it or not. (And don?t forget the ecosystem is
> much bigger than Java language alone)
>
> Gru?
> Bernd
> --
> https://bernd.eckenfels.net
>
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Olexandr Rotan <rotanolexandr842 at gmail.com>
> *Sent:* Tuesday, September 17, 2024 9:16 PM
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Does API for transformation of class files in Class-FIle API
> solves the same problem as code generationg annotation processors?
>
> Hello there. I am writing to address the overlap between class file
> transformation using the ClassFile API and the work done by code-generating
> annotation processors, and whether they ultimately solve the same problem.
>
> Annotations such as @Async and @Transactional in popular frameworks are
> good examples of code semantics being modified or extended at runtime,
> primarily through proxying mechanisms. In these cases, bytecode
> transformation is employed under the hood, as the annotations imply
> asynchronous execution or transactional boundaries.
>
> The general implication that I am aware of about annotations is that they
> can change code semantics. While I am not a fan of this, I can understand
> people that once set this rule. And so Class-File API exposing
> transformation API for class-files seems like legalizing the bypass of this
> rule. I, personally, am a fan of steps in this direction, since I like to
> write code generators that generate code for existing classes for fun from
> time to time, but that doesnt change my assumption that Class-File API
> somehow contradicts general rules applied to annotations by JDK, and it
> always seems kind of odd to me when some of API authors speaks so calmly
> about on-flight transformations of bytecode while even AST transformations
> in compile time aren't supported by JDK.
>
> Moreover, Class-File API seems like more than just an alternative to
> generating processors, but rather a weapon of mass destruction compared to
> later. Changes to bytecode are always unsafe, and their versatility makes
> them much more invasive.
>
> To me, personally, after this API is introduced, addressing long standing
> questions of libraries like lombok and more exotic ones like manifold seems
> to be an organic step. In my opinion, if even bytecode transformations are
> now legal, then much more safe AST transformations (which are safer because
> the compiler wont let through invalid AST, while bytecode transformations
> could cause silent errors) should also be addressed. SInce JDK historically
> mostly focused on code readability, many libraries picked up responsibility
> of easing writability, and "legalizing" them, in my opinion, would be a
> giant step in the right direction.
>
> So what am I missing here? Or is it really as it seems, that now that
> bytecode transformations are in public APIs, making invasive changes in
> compiled code is basically legalized? Would really appreciate it if someone
> could spare some time to make things clear for me.
>
> Best regards
>
> --
> https://bernd.eckenfels.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240918/833de0ae/attachment-0001.htm>

From viktor.klang at oracle.com  Wed Sep 18 10:33:03 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 18 Sep 2024 10:33:03 +0000
Subject: [External] : Re: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>
References: <20240902175543.44781778E42@eggemoggin.niobe.net>
 <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>
Message-ID: <MW4PR10MB5774DC5139E1068C3A9BB511FF622@MW4PR10MB5774.namprd10.prod.outlook.com>

Thanks David!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Monday, 2 September 2024 23:58
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Cc: Viktor Klang <viktor.klang at oracle.com>; jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: [External] : Re: New candidate JEP: 485: Stream Gatherers

Thanks. Glad to see this finally land. That slidingWindow and other related functions are extremely powerful.

On Mon, Sep 2, 2024 at 3:13?PM Mark Reinhold <mark.reinhold at oracle.com<mailto:mark.reinhold at oracle.com>> wrote:
https://openjdk.org/jeps/485

  Summary: Enhance the Stream API to support custom intermediate
  operations.  This will allow stream pipelines to transform data in ways
  that are not easily achievable with the existing built-in intermediate
  operations.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240918/14c28a0c/attachment.htm>

From rotanolexandr842 at gmail.com  Wed Sep 18 12:12:01 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 18 Sep 2024 15:12:01 +0300
Subject: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>
References: <20240902175543.44781778E42@eggemoggin.niobe.net>
 <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>
Message-ID: <CAL5bRt-icdkgyK2RqG36HbOGhP_+2FsGLwP+9KMkdd4X5WZPqg@mail.gmail.com>

Is in-built gatherers list finalized? I was thinking that
Gatherers::uniqueBy(Function<OUT, DISCRIMINATOR>) could be very popular
among stream users, although it is fairly easy to implement yourself (as
well as bunch of currently in-built ones though)

On Tue, Sep 3, 2024, 00:59 David Alayachew <davidalayachew at gmail.com> wrote:

> Thanks. Glad to see this finally land. That slidingWindow and other
> related functions are extremely powerful.
>
> On Mon, Sep 2, 2024 at 3:13?PM Mark Reinhold <mark.reinhold at oracle.com>
> wrote:
>
>> https://openjdk.org/jeps/485
>>
>>   Summary: Enhance the Stream API to support custom intermediate
>>   operations.  This will allow stream pipelines to transform data in ways
>>   that are not easily achievable with the existing built-in intermediate
>>   operations.
>>
>> - Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240918/f7e80866/attachment.htm>

From redestad at openjdk.org  Wed Sep 18 12:18:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Sep 2024 12:18:08 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v3]
In-Reply-To: <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
Message-ID: <z-PoWf3mYZAaP5W9MVd78Zec64VaUpx3kgT46-x9Krc=.c9f5e2d4-e82e-499f-8649-ae370fcb6de1@github.com>

On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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:
> 
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

How does archiving and resolution of the linked `MethodType` instances work? In particular how does archiving fill up the `MethodType::internTable` to ensure `MethodType` uniqueness?

src/java.base/share/classes/jdk/internal/misc/CDS.java line 80:

> 78: 
> 79:     /*
> 80:      * Wwhen dumping the static archive, CDS is able to archive MethodHandles.

Suggestion:

     * When dumping the static archive, CDS is able to archive MethodHandles.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2312480746
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764930471

From epeter at openjdk.org  Wed Sep 18 12:18:11 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Sep 2024 12:18:11 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v12]
In-Reply-To: <YTuwAMwWzDUteOb6zkIIPfoVp2IBCU2BLjJGMdN1q20=.a0cb7d5f-6ec3-4cca-9c2c-6439cee6180c@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <YTuwAMwWzDUteOb6zkIIPfoVp2IBCU2BLjJGMdN1q20=.a0cb7d5f-6ec3-4cca-9c2c-6439cee6180c@github.com>
Message-ID: <TTkfTzf0-_Yme9mgZMwrG0LA355ZXizQlU0tvWr-AKU=.6f42db0a-079b-4b79-bbd1-c10780bf0686@github.com>

On Wed, 18 Sep 2024 07:21:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporating review and documentation suggestions.

Generally, from a C2 point of view this looks good now.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2312501448

From epeter at openjdk.org  Wed Sep 18 12:18:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Sep 2024 12:18:12 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v10]
In-Reply-To: <jJKUBxW9OJSF-D6M0seaAivuvT8gjjBXQKiRM_GOS1U=.e620defe-737d-47a3-b0f6-29848aa73068@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7kLX2-XUHL8Ej4GyQD8V7my-bqK2EZrQEyZkgZWYA6k=.cbbab922-db74-4173-a529-e4faf65db0e6@github.com>
 <0Ak63KM4JYdbOT33Q8XPcv096MKzjY6vyl4xZkapZwM=.6b92e423-9bd5-4109-a0b3-75dbeaf40315@github.com>
 <jJKUBxW9OJSF-D6M0seaAivuvT8gjjBXQKiRM_GOS1U=.e620defe-737d-47a3-b0f6-29848aa73068@github.com>
Message-ID: <o7DhCEipM6CvUpI5dFTutQOoCaPuegnwYfDeof1FaqE=.a7cf8155-08d5-4423-ab7b-ed691597f70d@github.com>

On Tue, 17 Sep 2024 07:02:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2122:
>> 
>>> 2120:   // index format by subsequent VectorLoadShuffle.
>>> 2121:   int cast_vopc = VectorCastNode::opcode(0, index_elem_bt, true);
>>> 2122:   Node* index_byte_vec = phase->transform(VectorCastNode::make(cast_vopc, index_vec, T_BYTE, num_elem));
>> 
>> This cast assumes that the indices cannot have more than 8 bits. This would allow vector lengths of up to 256. This is fine for intel. But as far as I know ARM has in principle longer vectors - up to 2048 bytes. Should we maybe add some assert here to make sure we never badly truncate the index?
>
> Shuffle overhaul is on our todo list, its a know limitation which we tried lifting once, yes you read it correctly, its a limitation for AARCH64 SVE once a 2048 bits vector systems are available, IIRC current max vector size on any available AARCH64 system is 256 bits, with Neoverse V2 they shrink the vector size back to 16 bytes.

Are there any asserts that would catch this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1764943566

From epeter at openjdk.org  Wed Sep 18 12:26:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Sep 2024 12:26:12 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v2]
In-Reply-To: <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>
Message-ID: <BaR7EYBiZ49GpDDiEuglTF4vqeyhO3oMnPJGf40_E74=.6121a64d-8e74-4a53-9d2d-f17c6dcf8043@github.com>

On Fri, 13 Sep 2024 22:30:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>> 
>> Summary of changes is as follows:
>>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>> 
>> For the following source:
>> 
>> 
>>     public void test() {
>>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>>             index.selectFrom(inpvect).intoArray(byteres, j);
>>         }
>>     }
>> 
>> 
>> The code generated for inner main now looks as follows:
>> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>>   0x00007f40d02274d0:   movslq %ebx,%r13
>>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>>   0x00007f40d022751f:   add    $0x40,%ebx
>>   0x00007f40d0227522:   cmp    %r8d,%ebx
>>   0x00007f40d0227525:   jl     0x00007f40d02274d0
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I'm a bit confused by the name `shuffleWrapIndexes` and `inline_vector_shuffle_wrap_indexes`.

Are you **shuffling wrap-indexes**? I don't know what that would even mean. I think you should name it `wrapShuffleIndexes`. Or is there any naming convention in the VectorAPI that prevents this?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20634#pullrequestreview-2312528484

From winterhalter at openjdk.org  Wed Sep 18 12:37:15 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Wed, 18 Sep 2024 12:37:15 GMT
Subject: Integrated: 8337302: Undefined type variable results in null
In-Reply-To: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
Message-ID: <MKjcWFQ05BvyZlimGC1LJP3gmdbViLbTZWXCFZP1Iug=.cba4ce9d-1f41-4baa-a5f0-d0974def9ee0@github.com>

On Sun, 11 Aug 2024 22:25:40 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

This pull request has now been integrated.

Changeset: 1d070a32
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d070a3238a1cd8b9359357e6e3f751cd26a3f06
Stats:     86 lines in 3 files changed: 74 ins; 0 del; 12 mod

8337302: Undefined type variable results in null

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20535

From viktor.klang at oracle.com  Wed Sep 18 12:49:56 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 18 Sep 2024 12:49:56 +0000
Subject: [External] : Re: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <CAL5bRt-icdkgyK2RqG36HbOGhP_+2FsGLwP+9KMkdd4X5WZPqg@mail.gmail.com>
References: <20240902175543.44781778E42@eggemoggin.niobe.net>
 <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>
 <CAL5bRt-icdkgyK2RqG36HbOGhP_+2FsGLwP+9KMkdd4X5WZPqg@mail.gmail.com>
Message-ID: <MW4PR10MB57744B66FABBA74E6F5E0447FF622@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Olexandr,

The initial set of Gatherers is not currently planned to change. With that said, that doesn't mean that that set is fixed forever, rather we want to see what people end up having to re-implement and see which ones of those would make sense to incorporate down the line.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Olexandr Rotan <rotanolexandr842 at gmail.com>
Sent: Wednesday, 18 September 2024 14:12
To: David Alayachew <davidalayachew at gmail.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; Viktor Klang <viktor.klang at oracle.com>; jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: [External] : Re: New candidate JEP: 485: Stream Gatherers


Is in-built gatherers list finalized? I was thinking that Gatherers::uniqueBy(Function<OUT, DISCRIMINATOR>) could be very popular among stream users, although it is fairly easy to implement yourself (as well as bunch of currently in-built ones though)

On Tue, Sep 3, 2024, 00:59 David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Thanks. Glad to see this finally land. That slidingWindow and other related functions are extremely powerful.

On Mon, Sep 2, 2024 at 3:13?PM Mark Reinhold <mark.reinhold at oracle.com<mailto:mark.reinhold at oracle.com>> wrote:
https://openjdk.org/jeps/485

  Summary: Enhance the Stream API to support custom intermediate
  operations.  This will allow stream pipelines to transform data in ways
  that are not easily achievable with the existing built-in intermediate
  operations.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240918/c9d13796/attachment.htm>

From epeter at openjdk.org  Wed Sep 18 12:54:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Sep 2024 12:54:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
Message-ID: <JGM4W8ECoKlMOY-2Ybh7BpRyZKslT_i6YBQahDqv10M=.31588d65-6145-4f0a-94f7-0c95a154fb5c@github.com>

On Wed, 18 Sep 2024 12:34:58 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed code fragment from last review comment resolution.
>
> src/hotspot/cpu/x86/x86.ad line 6578:
> 
>> 6576:   %}
>> 6577:   ins_pipe( pipe_slow );
>> 6578: %}
> 
> Above, you name both the `format` and method name with `_reg` and `_mem`, but here you do not do it for the method name. Would be nice to keep it consistent.

Below you also do it inconsistently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764976079

From epeter at openjdk.org  Wed Sep 18 12:54:16 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Sep 2024 12:54:16 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
Message-ID: <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>

On Tue, 17 Sep 2024 07:14:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed code fragment from last review comment resolution.

Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests?
`src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`

Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?

src/hotspot/cpu/x86/x86.ad line 6578:

> 6576:   %}
> 6577:   ins_pipe( pipe_slow );
> 6578: %}

Above, you name both the `format` and method name with `_reg` and `_mem`, but here you do not do it for the method name. Would be nice to keep it consistent.

src/hotspot/cpu/x86/x86.ad line 10793:

> 10791:   match(Set dst (SaturatingAddV (Binary dst (LoadVector src)) mask));
> 10792:   match(Set dst (SaturatingSubV (Binary dst (LoadVector src)) mask));
> 10793:   format %{ "vector_saturating_unsigned_masked $dst, $mask, $src" %}

Suggestion:

  format %{ "vector_saturating_unsigned_subword_masked $dst, $mask, $src" %}

src/hotspot/share/opto/vectornode.hpp line 81:

> 79:   static VectorNode* shift_count(int opc, Node* cnt, uint vlen, BasicType bt);
> 80:   static VectorNode* make(int opc, Node* n1, Node* n2, uint vlen, BasicType bt, bool is_var_shift = false);
> 81:   static VectorNode* make(int vopc, Node* n1, Node* n2, const TypeVect* vt, bool is_mask = false, bool is_var_shift = false, bool is_unsigned = false);

Feels like this just slowly grows and grows... eventually we will have too many arguments. Not sure what is a better alternative though...

src/hotspot/share/opto/vectornode.hpp line 386:

> 384: class SaturatingSubVNode : public SaturatingVectorNode {
> 385:  public:
> 386:   SaturatingSubVNode(Node* in1, Node* in2, const TypeVect* vt, bool is_unsigned) : SaturatingVectorNode(in1,in2,vt,is_unsigned) {}

Suggestion:

  SaturatingSubVNode(Node* in1, Node* in2, const TypeVect* vt, bool is_unsigned) : SaturatingVectorNode(in1, in2, vt, is_unsigned) {}

spaces required by style guide

src/hotspot/share/opto/vectornode.hpp line 598:

> 596: class UMinVNode : public VectorNode {
> 597:  public:
> 598:   UMinVNode(Node* in1, Node* in2, const TypeVect* vt) : VectorNode(in1,in2,vt) {

Suggestion:

  UMinVNode(Node* in1, Node* in2, const TypeVect* vt) : VectorNode(in1, in2, vt) {

spaces required by style guide

src/hotspot/share/opto/vectornode.hpp line 614:

> 612: class UMaxVNode : public VectorNode {
> 613:  public:
> 614:   UMaxVNode(Node* in1, Node* in2, const TypeVect* vt) : VectorNode(in1,in2,vt) {

Suggestion:

  UMaxVNode(Node* in1, Node* in2, const TypeVect* vt) : VectorNode(in1, in2, vt) {

spaces required by style guide

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2312554183
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764975321
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764982201
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764985438
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764987143
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764987547
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1764988807

From mullan at openjdk.org  Wed Sep 18 13:02:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 18 Sep 2024 13:02:05 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <SVsgyTKcBu5UFJmi2-KqNLxMMNI01ufn3wrK-v6RYv0=.9fedc211-7ecf-41b3-ac93-849461329cc1@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

src/java.base/share/classes/javax/net/SocketFactory.java line 63:

> 61:  * <P> Factory classes are specified by environment-specific configuration
> 62:  * mechanisms.  For example, the <em>getDefault</em> method could return
> 63:  * a factory that was appropriate for a particular user, and a

Suggest changing this to "particular application" instead of "particular user" as it seems a bit odd to be talking about users here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765011733

From jbhateja at openjdk.org  Wed Sep 18 13:43:32 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 13:43:32 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v14]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <jttVx9d2dTstoz0tOPnC8NOf-i34J-RdlEmdZcFJRA4=.39deba13-1de9-48f1-b42b-8f72cdfb25e9@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/a6f8ee8b..5253706e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=12-13

  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From lucy at openjdk.org  Wed Sep 18 13:45:04 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 18 Sep 2024 13:45:04 GMT
Subject: RFR: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
In-Reply-To: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
References: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
Message-ID: <Wy2780SP3-Zj_Q6JIK9Rx0dyDkvgHX9EA7w2MlPI0og=.2694c3fb-f08d-4da4-9c3d-86c9076c920f@github.com>

On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).

Looks good. And trivial.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20960#pullrequestreview-2312744653

From jbhateja at openjdk.org  Wed Sep 18 13:47:08 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 13:47:08 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
Message-ID: <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>

On Wed, 18 Sep 2024 12:51:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests? `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> 
> Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?

Nomenclature is suggested by Paul. 

We have sufficient test coverage of these APIs in JTREG tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2358514597

From jbhateja at openjdk.org  Wed Sep 18 13:47:10 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 13:47:10 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <JGM4W8ECoKlMOY-2Ybh7BpRyZKslT_i6YBQahDqv10M=.31588d65-6145-4f0a-94f7-0c95a154fb5c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <JGM4W8ECoKlMOY-2Ybh7BpRyZKslT_i6YBQahDqv10M=.31588d65-6145-4f0a-94f7-0c95a154fb5c@github.com>
Message-ID: <bbosbRqXV5PfmhrfVB4tVh3P4YXtBDizaTWGKhmI6H8=.d868183c-d648-402c-9de1-8523eb5e596f@github.com>

On Wed, 18 Sep 2024 12:35:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 6578:
>> 
>>> 6576:   %}
>>> 6577:   ins_pipe( pipe_slow );
>>> 6578: %}
>> 
>> Above, you name both the `format` and method name with `_reg` and `_mem`, but here you do not do it for the method name. Would be nice to keep it consistent.
>
> Below you also do it inconsistently.

> Above, you name both the `format` and method name with `_reg` and `_mem`, but here you do not do it for the method name. Would be nice to keep it consistent.

Memory operands are sufficient to implicitly infer memory flavor of opto assembly instruction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1765088839

From epeter at openjdk.org  Wed Sep 18 14:25:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Sep 2024 14:25:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
Message-ID: <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>

On Wed, 18 Sep 2024 13:44:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests? `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> 
> Nomenclature is suggested by Paul.

@PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?

> 
> We have sufficient test coverage of these APIs in JTREG tests.

@jatin-bhateja I can't see any dedicated JTREG tests to the `VectorMath` methods. I only see the VectorAPI tests. Can you point me to the `VectorMath` tests? I'd like to review them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2358617657

From sviswanathan at openjdk.org  Wed Sep 18 15:30:10 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 18 Sep 2024 15:30:10 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v2]
In-Reply-To: <BaR7EYBiZ49GpDDiEuglTF4vqeyhO3oMnPJGf40_E74=.6121a64d-8e74-4a53-9d2d-f17c6dcf8043@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>
 <BaR7EYBiZ49GpDDiEuglTF4vqeyhO3oMnPJGf40_E74=.6121a64d-8e74-4a53-9d2d-f17c6dcf8043@github.com>
Message-ID: <x4W9nAbLjwAxoy8K9wX63ZxURaacirzQCSgiOQRsw1o=.c3c06723-f4e2-4fa8-b41d-81e9a0f67274@github.com>

On Wed, 18 Sep 2024 12:23:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I'm a bit confused by the name `shuffleWrapIndexes` and `inline_vector_shuffle_wrap_indexes`.
> 
> Are you **shuffling wrap-indexes**? I don't know what that would even mean. I think you should name it `wrapShuffleIndexes`. Or is there any naming convention in the VectorAPI that prevents this?

Agree, wrapShuffleIndexes makes more sense. I will make the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2358784233

From bpb at openjdk.org  Wed Sep 18 15:55:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Sep 2024 15:55:11 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <7bAlcZ3zTDLnSZmeTJaYdGY6skXLV7S77CkIR2Y3l2c=.a78fa91b-0408-42ed-abb2-45b76cbe2253@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
 <7bAlcZ3zTDLnSZmeTJaYdGY6skXLV7S77CkIR2Y3l2c=.a78fa91b-0408-42ed-abb2-45b76cbe2253@github.com>
Message-ID: <jMcfXgzpYyxv2ltTLuCSoB6hOCwCB_2nKTnwkil7Bn8=.5623edd5-7ac7-4609-8b92-c75ba156f185@github.com>

On Wed, 18 Sep 2024 05:54:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The current state of this PR looks good to me. I'll review the CSR too.

Thanks, @jaikiran, for your assistance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2358842957

From mcimadamore at openjdk.org  Wed Sep 18 15:59:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Sep 2024 15:59:42 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods
Message-ID: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>

This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).

This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.

The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.

The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/21067/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338596
  Stats: 118 lines in 4 files changed: 76 ins; 40 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From qamai at openjdk.org  Wed Sep 18 16:15:38 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 18 Sep 2024 16:15:38 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation
Message-ID: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>

Hi,

This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.

Regarding the related issues:

- [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
- [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
- [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.

Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.

Please take a look and leave reviews. Thanks a lot.

The description of the original PR:

This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:

Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
Upon these changes, a `rearrange` can emit more efficient code:

    var species = IntVector.SPECIES_128;
    var v1 = IntVector.fromArray(species, SRC1, 0);
    var v2 = IntVector.fromArray(species, SRC2, 0);
    v1.rearrange(v2.toShuffle()).intoArray(DST, 0);

    Before:
    movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
    vmovdqu 0x10(%r10),%xmm2
    movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
    vmovdqu 0x10(%r10),%xmm1
    movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
    vmovdqu 0x10(%r10),%xmm0
    vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
                                                            ;   {external_word}
    vpackusdw %xmm0,%xmm0,%xmm0
    vpackuswb %xmm0,%xmm0,%xmm0
    vpmovsxbd %xmm0,%xmm3
    vpcmpgtd %xmm3,%xmm1,%xmm3
    vtestps %xmm3,%xmm3
    jne    0x00007fc2acb4e0d8
    vpmovzxbd %xmm0,%xmm0
    vpermd %ymm2,%ymm0,%ymm0
    movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
    vmovdqu %xmm0,0x10(%r10)

    After:
    movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
    vmovdqu 0x10(%r10),%xmm1
    movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
    vmovdqu 0x10(%r10),%xmm2
    vpxor  %xmm0,%xmm0,%xmm0
    vpcmpgtd %xmm2,%xmm0,%xmm3
    vtestps %xmm3,%xmm3
    jne    0x00007fa818b27cb1
    vpermd %ymm1,%ymm2,%ymm0
    movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
    vmovdqu %xmm0,0x10(%r10)

-------------

Commit messages:
 - copyright year
 - remove LoadShuffle from riscv, whitespace
 - tighten concrete types
 - [vectorapi] Refactor VectorShuffle implementation

Changes: https://git.openjdk.org/jdk/pull/21042/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310691
  Stats: 4984 lines in 64 files changed: 2984 ins; 981 del; 1019 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From qamai at openjdk.org  Wed Sep 18 16:15:38 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 18 Sep 2024 16:15:38 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <et39ifSpbD62eQDltK_0DacSWkF70FYj-Q7YSEid_HM=.28628102-cd5f-48fc-8cb1-6b45680915ba@github.com>

On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

@PaulSandoz What do you think regarding x86-32?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2356451016

From psandoz at openjdk.org  Wed Sep 18 16:15:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 16:15:38 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <et39ifSpbD62eQDltK_0DacSWkF70FYj-Q7YSEid_HM=.28628102-cd5f-48fc-8cb1-6b45680915ba@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <et39ifSpbD62eQDltK_0DacSWkF70FYj-Q7YSEid_HM=.28628102-cd5f-48fc-8cb1-6b45680915ba@github.com>
Message-ID: <l79GB9tZB4pAZTiCtOkbgP9ExJhiwe7wS0RD3DW0Iww=.15173890-d3bb-4ddd-9010-ae7e0ab8f7d0@github.com>

On Tue, 17 Sep 2024 16:59:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> @PaulSandoz What do you think regarding x86-32?

I don't see anything obvious in the changes of this PR that would affect x86-32, but i ain't a HotSpot expert. Perhaps this just exacerbates some existing bug?@sviswa7 what do you think?

My sense is to proceed, and problem list the failure, and attempt to find the source of the failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2357043269

From sviswanathan at openjdk.org  Wed Sep 18 16:15:38 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 18 Sep 2024 16:15:38 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <l79GB9tZB4pAZTiCtOkbgP9ExJhiwe7wS0RD3DW0Iww=.15173890-d3bb-4ddd-9010-ae7e0ab8f7d0@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <et39ifSpbD62eQDltK_0DacSWkF70FYj-Q7YSEid_HM=.28628102-cd5f-48fc-8cb1-6b45680915ba@github.com>
 <l79GB9tZB4pAZTiCtOkbgP9ExJhiwe7wS0RD3DW0Iww=.15173890-d3bb-4ddd-9010-ae7e0ab8f7d0@github.com>
Message-ID: <5oex8dW9c0zy1RNdWjuA3bpaxACV_QGt3iij6SJ2kZ8=.a3d18f15-ed92-4d79-9df8-9e2d828fb33c@github.com>

On Tue, 17 Sep 2024 22:29:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > @PaulSandoz What do you think regarding x86-32?
> 
> I don't see anything obvious in the changes of this PR that would affect x86-32, but i ain't a HotSpot expert. Perhaps this just exacerbates some existing bug?@sviswa7 what do you think?
> 
> My sense is to proceed, and problem list the failure, and attempt to find the source of the failure.

Yes, let us proceed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2357222835

From qamai at openjdk.org  Wed Sep 18 16:15:38 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 18 Sep 2024 16:15:38 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <l79GB9tZB4pAZTiCtOkbgP9ExJhiwe7wS0RD3DW0Iww=.15173890-d3bb-4ddd-9010-ae7e0ab8f7d0@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <et39ifSpbD62eQDltK_0DacSWkF70FYj-Q7YSEid_HM=.28628102-cd5f-48fc-8cb1-6b45680915ba@github.com>
 <l79GB9tZB4pAZTiCtOkbgP9ExJhiwe7wS0RD3DW0Iww=.15173890-d3bb-4ddd-9010-ae7e0ab8f7d0@github.com>
Message-ID: <rKbMxVDfcXf-ZmjLaMLnk2S5I0r3dIQWSO02VHH9Qv4=.9e50189b-5880-4c18-bdaf-74c4fd15a41f@github.com>

On Tue, 17 Sep 2024 22:29:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @PaulSandoz What do you think regarding x86-32?
>
>> @PaulSandoz What do you think regarding x86-32?
> 
> I don't see anything obvious in the changes of this PR that would affect x86-32, but i ain't a HotSpot expert. Perhaps this just exacerbates some existing bug?@sviswa7 what do you think?
> 
> My sense is to proceed, and problem list the failure, and attempt to find the source of the failure.

@PaulSandoz @sviswa7 Thanks for your advice, I have made the PR ready for review

@iwanowww Could you take another look at this, please?

@jatin-bhateja Could you verify that [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) does not occur?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2358879014

From jbhateja at openjdk.org  Wed Sep 18 16:22:30 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 16:22:30 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v15]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <mBbQIxlNlRp_qYSt1XQo3Unnl1MLYN9pLB1M6iiLz9k=.23e73e07-2257-49d1-b6bd-3045cd30ca17@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Test cleanups.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/5253706e..f81b2525

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=13-14

  Stats: 370 lines in 11 files changed: 10 ins; 360 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Wed Sep 18 16:26:13 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Sep 2024 16:26:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
Message-ID: <ZUkbr63I9JXdn7vzCi7Anlup_u9_guThPwYQcVbKtQ0=.a022d39e-e674-481f-9fae-b15be972de15@github.com>

On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > > Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests? `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > 
> > 
> > Nomenclature is suggested by Paul.
> 
> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> 
> > We have sufficient test coverage of these APIs in JTREG tests.
> 
> @jatin-bhateja I can't see any dedicated JTREG tests to the `VectorMath` methods. I only see the VectorAPI tests. Can you point me to the `VectorMath` tests? I'd like to review them.

https://github.com/openjdk/jdk/pull/20507/files#diff-6031c9066a7d7a90cc002e93a1eb64f0371f09d385f42289d202426cc7516d2fR3019-R3264

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2358909462

From dev at anthonyv.be  Wed Sep 18 16:27:30 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Wed, 18 Sep 2024 16:27:30 +0000
Subject: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>

Hi Viktor

Let me start with a question: is the requirement (a) "a Gatherer SHOULD be reusable", or (b) "a Gatherer MUST be reusable"?
As of today the specification says (b), whereas the implementation matches (a).

In case of (a), I propose to align the specification to allow for compliant, non-reusable Gatherers.

In case of (b), I propose to align the implementation to enforce compliance. Something like:
(1) invoke `initializer()` twice, giving `i1` and `i2`. Discard `i1` and invoke `i2` twice, giving `state1` and `state2`.
(2) invoke `finisher()` twice, giving `f1` and `f2`. Discard `f1` and invoke `f2` twice, the first time with `state1` and a dummy Downstream, the second time with the actual final state, i.e. `state2` after all elements were integrated, and the actual Downstream.
Then backport this change to JDK 23 & 22 and/or do another round of preview in JDK 24.
I'm confident that enforcing compliance would result in significant amounts of feedback questioning the requirement.

My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.

Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction. You say:

> And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.

so I'd guess the rationale is "protecting the users from being given non-reusable Gatherers".
However, I can't readily think of a situation where this would be essential.
If a user creates a Gatherer by invoking a factory method, the factory method can specify whether its result is reusable.
And if a user is given a Gatherer as a method argument, and they need the Gatherer to be reusable, they could change the parameter to a `Supplier<Gatherer>` instead.

> >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
> 
> There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.

We agree, just that I'd provide 2 factory methods, `concat(Stream<T>)` (non-reusable) and `append(List<T>)` (reusable), whereas you'd provide a 2-in-1 `concat(Supplier<Stream<T>>)`.

Kind regards, Anthony

September 12, 2024 at 11:55 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> Hi Anthony
> 
> Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.
> 
> >While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
> 
> To me, this is governed by the following parts of the Gatherer specification https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html :
> 
> "Each invocation of initializer() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer() ,integrator() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator() ,combiner() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner() , and finisher() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher() ?must return a semantically identical result."
> 
> and
> 
> "Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstreamGatherer.Downstream https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html PREVIEW https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream ?for longer than the invocation duration of the method which they are passed to."
> 
> And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
> 
> For Stream, the assumption is that they are NOT reusable at all.
> For Gatherer, I think the only reasonable assumption is that they are reusable.
> 
> >In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?
> 
> Not necessarily, if the factory method **consumes**?the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.
> 
> >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
> 
> There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
> 
> >As another example, take Gunnar Morling's zip Gatherers:?
> 
> I don't see how Gatherers like this could be made reusable, or why that would even be desirable.
> 
> Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().
> 
> >My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
> 
> My apologies, I misunderstood. To me, the operation you describe is called `inject`.
> Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.
> 
> Thanks again for the great questions and conversation, it's valuable!
> Cheers,
> 
> ?
> 
> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle
>

From psandoz at openjdk.org  Wed Sep 18 16:56:13 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 16:56:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
Message-ID: <rHYOu1rSW3Iy9CNsYpRuD7hrvUGLmpi0Rutk9GZ9R4A=.750e81f8-c9e3-4746-a958-1f21f32f0805@github.com>

On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > 
> > 
> > Nomenclature is suggested by Paul.
> 
> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> 

It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.


/**
 * The class {@code VectorMath} contains methods for performing
 * scalar numeric operations in support of vector numeric operations.
 */
public final class VectorMath {


These are referenced by the vector operators e.g.,


    /** Produce saturating {@code a+b}.  Integral only.
     * @see VectorMath#addSaturating(int, int)
     */
    public static final Binary SADD = binary("SADD", "+", VectorSupport.VECTOR_OP_SADD, VO_NOFP);


And in addition these methods would be used by any tail computation (and the fallback code).

At the moment we are uncertain whether such operations should reside elsewhere and we did not want to block progress. I am not beholden to the name, but so far i cannot think of a concise alternative.`VectorOperatorMath` is arguably more precise but more verbose.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2358973116

From sviswanathan at openjdk.org  Wed Sep 18 17:00:30 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 18 Sep 2024 17:00:30 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v3]
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <ejjSF36eH_T1oSpZTNgdcE-ayvxalBb6U0brArvq4K4=.642fa6e6-e424-4f9c-ad74-3b752241547c@github.com>

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Change method name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20634/files
  - new: https://git.openjdk.org/jdk/pull/20634/files/428f2289..87e103ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=01-02

  Stats: 45 lines in 37 files changed: 0 ins; 0 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/20634.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20634/head:pull/20634

PR: https://git.openjdk.org/jdk/pull/20634

From psandoz at openjdk.org  Wed Sep 18 17:07:11 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 17:07:11 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v15]
In-Reply-To: <mBbQIxlNlRp_qYSt1XQo3Unnl1MLYN9pLB1M6iiLz9k=.23e73e07-2257-49d1-b6bd-3045cd30ca17@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <mBbQIxlNlRp_qYSt1XQo3Unnl1MLYN9pLB1M6iiLz9k=.23e73e07-2257-49d1-b6bd-3045cd30ca17@github.com>
Message-ID: <bvS4fW6kt5rgZVh30wG-J1xdUXKhQA50q60rgrlA3s4=.dbe499b0-60c3-4ecb-8af5-f1f598949d74@github.com>

On Wed, 18 Sep 2024 16:22:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanups.

> > > Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests? `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> > We have sufficient test coverage of these APIs in JTREG tests.
> 
> @jatin-bhateja I can't see any dedicated JTREG tests to the `VectorMath` methods. I only see the VectorAPI tests. Can you point me to the `VectorMath` tests? I'd like to review them.

I think Jatin is relying on the vector tests to also test the scalar operations by virtue that eventually the scalar result will be compared with the C2 result. Although both might produced the same result both maybe incorrect! We need some independent scalar tests, especially so if later on these are also made intrinsic. I shall volunteer to add some.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2358992714

From psandoz at openjdk.org  Wed Sep 18 17:21:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 17:21:04 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <gCE_ncsFP9Gjvcwj2Iq3mGy1RVICqdV5cjwzxq_-YFY=.f5b21db4-1d94-4d60-a91c-f4a4181df941@github.com>

On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Will this have any direct impact on the changes proposed by #20508 and #20634?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2359018872

From sviswanathan at openjdk.org  Wed Sep 18 17:26:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 18 Sep 2024 17:26:06 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <gCE_ncsFP9Gjvcwj2Iq3mGy1RVICqdV5cjwzxq_-YFY=.f5b21db4-1d94-4d60-a91c-f4a4181df941@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <gCE_ncsFP9Gjvcwj2Iq3mGy1RVICqdV5cjwzxq_-YFY=.f5b21db4-1d94-4d60-a91c-f4a4181df941@github.com>
Message-ID: <Qorjri1VROQx3nI_9aTFk0frI1tuH0GVu3VhI97NNMA=.c2a5b16e-0baf-49a9-b835-68d588bd2dc7@github.com>

On Wed, 18 Sep 2024 17:18:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Will this have any direct impact on the changes proposed by #20508 and #20634?

I think we should first get the 20508 and 20634 integrated before this one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2359026443

From qamai at openjdk.org  Wed Sep 18 17:51:13 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 18 Sep 2024 17:51:13 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <wlDOE40ZdD_VAi9sFcgjrGdkr3PKYLw-taHDnpgHcVs=.e7074ddc-0097-4390-b322-142f278d3be9@github.com>

On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Got it, I think https://github.com/openjdk/jdk/pull/20508 and this PR are unrelated implementation-wise, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2359070587

From jlu at openjdk.org  Wed Sep 18 17:59:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Sep 2024 17:59:40 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21046/files
  - new: https://git.openjdk.org/jdk/pull/21046/files/731e4ee1..19d6b725

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21046/head:pull/21046

PR: https://git.openjdk.org/jdk/pull/21046

From jlu at openjdk.org  Wed Sep 18 17:59:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Sep 2024 17:59:40 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
 <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>
 <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com>
Message-ID: <G8zQH_nwQnDcM9yl9hT1_qcO4jUcZ662fONQQfzPrs8=.e5f57506-7f88-4dc3-b981-995769d87e83@github.com>

On Wed, 18 Sep 2024 06:52:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.
>> 
>> given the thread name `blink`, perhaps we could just use `blink()` in this example.
>
> Don't waste too much time on the "Java Thread Primitive Deprecation" page. The last remnant is the no-arg Thread.stop method which throws UOE unconditionally. Once that is removed then the doc-file pages will be removed too.

Kept it simple and simply replaced with Sean's suggestion of `blink()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481816

From jlu at openjdk.org  Wed Sep 18 17:59:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Sep 2024 17:59:41 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <jji2cBznsQxB3R4AhXAcrpB4VjoBZM9FnHvPm1W23mI=.455655bc-617a-48c4-bb48-59c6d111d48d@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <jji2cBznsQxB3R4AhXAcrpB4VjoBZM9FnHvPm1W23mI=.455655bc-617a-48c4-bb48-59c6d111d48d@github.com>
Message-ID: <DezYxErxpnSftJWX_8ZgzPEiMetyuwIsjXsst4NMiYg=.c6248404-5be4-4c0b-9793-5bce8040f93e@github.com>

On Wed, 18 Sep 2024 06:53:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review comments
>
> src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39:
> 
>> 37:  * implementation classes.  Charset providers may be installed in an instance
>> 38:  * of the Java platform as extensions.  Providers may also be made available by
>> 39:  * adding them to the application class path or by some other
> 
> They can also be deployed on the application module path, maybe need a separate JBS issue to clarify that part of the spec, and add a test.

Filed https://bugs.openjdk.org/browse/JDK-8340404 to handle this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481753

From jvernee at openjdk.org  Wed Sep 18 18:10:05 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Sep 2024 18:10:05 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <zlFJpW0dkbUCs3jJXORfvTSbh2mPtSPk8U92asTZDKw=.9eb507b3-64b6-4786-a340-b9dec8a9f3d6@github.com>

On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Is the `java/lang/foreign` package still the right place for this? (Maybe it should be under `java/lang`).

src/java.base/share/classes/java/lang/foreign/doc-files/RestrictedMethods.html line 34:

> 32: 
> 33: Some methods in the Java SE API are considered <em>restricted</em>. Restricted methods
> 34: are typically used to bind native foreign data and/or functions to first-class

I feel like a short general description is warranted here as well. Maybe something like: 'Restricted methods are APIs that can, when used incorrectly, violate the integrity of the Java Virtual Machine, but are conditionally made available to users as they provide essential functionality'

src/java.base/share/classes/java/lang/foreign/doc-files/RestrictedMethods.html line 39:

> 37: can be used to create a fresh segment with the same address and temporal bounds, but with
> 38: the provided size. This can be useful to resize memory segments obtained when
> 39: interacting with native functions.

This example is now talking about 'segment'/'address'/'temporal bounds' without the context of the other text in the package-info file, which seems a bit confusing. I suggest removing the example here, as essentially the same example is given in the next paragraph as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2313392631
PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1765490635
PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1765482794

From coffeys at openjdk.org  Wed Sep 18 18:27:05 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Sep 2024 18:27:05 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <RaZVwywXR8TW4czxCx9GxZaOBxDRpuMgcSqqhrLtqpE=.51210f45-79e3-4b28-9be8-acdeea9446cf@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Marked as reviewed by coffeys (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313447275

From naoto at openjdk.org  Wed Sep 18 19:57:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Sep 2024 19:57:04 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <kGTXCt-AVa41xlO984dfN8qO-Mws1F6OVaHnbVQ73sY=.e54d9472-fd20-4d61-b3dd-8c7b583e89e1@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313649127

From iris at openjdk.org  Wed Sep 18 20:28:01 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Sep 2024 20:28:01 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <HXJW7fwPt_TU0EkmwIi_336Mc-gdWZmcjhhjZ2Dr82U=.a6ae8354-a081-4669-af24-944fa009370c@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Happy to see us getting one step closer to removing Applets.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313706558

From rriggs at openjdk.org  Wed Sep 18 20:48:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Sep 2024 20:48:41 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <Hf2A8l2jlnSoGop98pzLuq4XVQB_bkrU0zc8kMWV354=.121d823c-a9e7-47cd-b2bd-c79586588f3e@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313767821

From lancea at openjdk.org  Wed Sep 18 21:01:43 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Sep 2024 21:01:43 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <rfMAUPrDYAlvr8WyIFHKjaK1TxLX96vsaT7Ui5nToxI=.8f3e36d9-996d-4f73-80f1-855fbc2b11db@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313789102

From dholmes at openjdk.org  Thu Sep 19 02:55:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Sep 2024 02:55:35 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods
In-Reply-To: <zlFJpW0dkbUCs3jJXORfvTSbh2mPtSPk8U92asTZDKw=.9eb507b3-64b6-4786-a340-b9dec8a9f3d6@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <zlFJpW0dkbUCs3jJXORfvTSbh2mPtSPk8U92asTZDKw=.9eb507b3-64b6-4786-a340-b9dec8a9f3d6@github.com>
Message-ID: <sz2vfYUdWWpo-RPdTcq3ASnO47jIE73Xf7c5FGdTGok=.c8022a70-7c7a-4ee7-a136-032a5a5861cc@github.com>

On Wed, 18 Sep 2024 18:07:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Is the java/lang/foreign package still the right place for this? (Maybe it should be under java/lang).

I agree, the scope for this is now outside the foreign package.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2359873181

From dholmes at openjdk.org  Thu Sep 19 03:02:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Sep 2024 03:02:34 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <XH6kvzP6J5_bzVziFnygM0mV8gc4M9WP9yc4VOT5H1E=.6c72b5fc-2bcb-44f4-b6b5-05a24a7c933d@github.com>

On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

As I wrote in the CSR request for the JEP:

> I think each method that is restricted and/or caller-sensitive should specify what happens when called when there is no caller context. We should use `AccessibleObject::canAccess` as an exemplar here:
> 
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/reflect/AccessibleObject.html#canAccess(java.lang.Object)
> 
> I have no doubt other caller-sensitive methods have failed to do this to date, but that should be fixed.
> 

This has to be mentioned in e.g. the javadoc for `System.loadLibrary`.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2314283214

From dholmes at openjdk.org  Thu Sep 19 03:02:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Sep 2024 03:02:35 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods
In-Reply-To: <zlFJpW0dkbUCs3jJXORfvTSbh2mPtSPk8U92asTZDKw=.9eb507b3-64b6-4786-a340-b9dec8a9f3d6@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <zlFJpW0dkbUCs3jJXORfvTSbh2mPtSPk8U92asTZDKw=.9eb507b3-64b6-4786-a340-b9dec8a9f3d6@github.com>
Message-ID: <IJ29fnh5UeKf_LLimkXcWHlpA1f1WfQ8R-On15fcSuI=.abb5d3f3-fd64-42cf-812f-b41cd37b243c@github.com>

On Wed, 18 Sep 2024 18:03:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> src/java.base/share/classes/java/lang/foreign/doc-files/RestrictedMethods.html line 34:
> 
>> 32: 
>> 33: Some methods in the Java SE API are considered <em>restricted</em>. Restricted methods
>> 34: are typically used to bind native foreign data and/or functions to first-class
> 
> I feel like a short general description is warranted here as well. Maybe something like: 'Restricted methods are APIs that can, when used incorrectly, violate the integrity of the Java Virtual Machine, but are conditionally made available to users, as they provide essential functionality'

I agree, the current text is still very FFM centric.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1766078214

From lmesnik at openjdk.org  Thu Sep 19 03:12:08 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 19 Sep 2024 03:12:08 GMT
Subject: RFR: 8340415: Update failure handler to print more info using gdb
 scripts
Message-ID: <oFgbw8IQ9sR62aP3-7R-Bcc8G9Yil6MXo2qelFPorkg=.95960644-36c6-469f-b99b-7a1768e01644@github.com>

The failure handler updated to use gdb scripts.
The initial version print some information about mutextes, safepoint and threads state. So the deadlocks are easier to analyze without opening core files.
The existing gdb processing is not changed.


Later the script might be improved with more information.

-------------

Commit messages:
 - efh updated

Changes: https://git.openjdk.org/jdk/pull/21078/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340415
  Stats: 212 lines in 5 files changed: 201 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21078/head:pull/21078

PR: https://git.openjdk.org/jdk/pull/21078

From amitkumar at openjdk.org  Thu Sep 19 04:36:39 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 19 Sep 2024 04:36:39 GMT
Subject: RFR: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
In-Reply-To: <Wy2780SP3-Zj_Q6JIK9Rx0dyDkvgHX9EA7w2MlPI0og=.2694c3fb-f08d-4da4-9c3d-86c9076c920f@github.com>
References: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
 <Wy2780SP3-Zj_Q6JIK9Rx0dyDkvgHX9EA7w2MlPI0og=.2694c3fb-f08d-4da4-9c3d-86c9076c920f@github.com>
Message-ID: <mYAxO7JJOdH3CFec32P1gXrhQ5JIGTuSeyKobiuXvUA=.c09b89a7-6c64-4587-b785-31d4f9be737f@github.com>

On Wed, 18 Sep 2024 13:42:10 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
>
> Looks good. And trivial.

Thank you @RealLucy  :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20960#issuecomment-2359955779

From amitkumar at openjdk.org  Thu Sep 19 04:36:40 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 19 Sep 2024 04:36:40 GMT
Subject: Integrated: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
In-Reply-To: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
References: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
Message-ID: <PJnzJXRuYW6gh2Ezy7zCWHIXh5ZvBSc2f8CLbAUjMCE=.b9ad9eb3-f514-499b-abdb-fe58d68bc0d1@github.com>

On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).

This pull request has now been integrated.

Changeset: 537447f8
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/537447f8816129dad9a1edd21bd30f3edf69ea60
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java

Reviewed-by: lucy

-------------

PR: https://git.openjdk.org/jdk/pull/20960

From amitkumar at openjdk.org  Thu Sep 19 05:06:40 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 19 Sep 2024 05:06:40 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v5]
In-Reply-To: <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
Message-ID: <NW7RnSebixCDMAy1OxvxA0z5_eu65p7JIkUk2Rn1o0s=.d54719e4-a3a0-4a66-b364-4fc7b938734b@github.com>

On Fri, 6 Sep 2024 17:51:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove PC save/restore on s390

src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3063:

> 3061:     address start = __ pc();
> 3062: 
> 3063:     __ resolve_jobject(Z_ARG1, Z_tmp_1, Z_tmp_2);

@JornVernee is it possible to rebase to head stream ? If there are no issue on other archs :-) 

I have implemented `resolve_global_jobject` method for s390x and merged changes to head stream with PR https://github.com/openjdk/jdk/pull/20986. Once rebased you can push below change. 

Suggestion:

    __ resolve_global_jobject(Z_ARG1, Z_tmp_1, Z_tmp_2);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1766163197

From jpai at openjdk.org  Thu Sep 19 06:30:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Sep 2024 06:30:41 GMT
Subject: Integrated: 8286851: Deprecate for removal several of the undocumented
 java launcher options
In-Reply-To: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
References: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
Message-ID: <hXSOLo18wnn89IqZBLLdDxe1_LMiZVRXwvyUixhu_Tw=.4742ac25-a003-437b-9cc1-d67d69caf33b@github.com>

On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate several outdated and undocumented java launcher options? This addresses https://bugs.openjdk.org/browse/JDK-8286851.
> 
> Specifically, the non-standard launcher options `-verbosegc`, `-noclassgc`, `-verify`, `-verifyremote`, `-ss`, `-ms` and `-mx` will be deprecated for removal. With this change, a deprecation warning will be printed, if any of these options are used.
> 
> No new tests have been added for this change. Existing tests in tier1, tier2 and tier3 continue to pass.
> 
> I'll create a CSR shortly for this change.

This pull request has now been integrated.

Changeset: 67198992
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67198992ce92da1ee615a73937f22fdaba28fba1
Stats:     7 lines in 1 file changed: 6 ins; 1 del; 0 mod

8286851: Deprecate for removal several of the undocumented java launcher options

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/21031

From jpai at openjdk.org  Thu Sep 19 06:30:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Sep 2024 06:30:41 GMT
Subject: RFR: 8286851: Deprecate for removal several of the undocumented
 java launcher options
In-Reply-To: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
References: <cch91os37tt99WIHq-YL6rkBvF-B1CgCSK6IhCIfrsc=.dfed2af3-7fc4-41d3-af64-76dfec7de9e1@github.com>
Message-ID: <3YJToVLwk2nHjGRK5jNUQXP-ciZgzveqWUH9WVH6lXY=.4a4475a6-4699-4843-a52b-82a71ad22f9f@github.com>

On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to deprecate several outdated and undocumented java launcher options? This addresses https://bugs.openjdk.org/browse/JDK-8286851.
> 
> Specifically, the non-standard launcher options `-verbosegc`, `-noclassgc`, `-verify`, `-verifyremote`, `-ss`, `-ms` and `-mx` will be deprecated for removal. With this change, a deprecation warning will be printed, if any of these options are used.
> 
> No new tests have been added for this change. Existing tests in tier1, tier2 and tier3 continue to pass.
> 
> I'll create a CSR shortly for this change.

Thank you David for the review here and on the CSR.

I've run our CI tests all the way through tier8 to make sure that this additional deprecation logging doesn't cause unexpected failures in tests (there was one test which needed to be fixed and that has now been integrated too). I'll go ahead with the integration of this PR now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21031#issuecomment-2360095915

From epeter at openjdk.org  Thu Sep 19 06:31:43 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 19 Sep 2024 06:31:43 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <rHYOu1rSW3Iy9CNsYpRuD7hrvUGLmpi0Rutk9GZ9R4A=.750e81f8-c9e3-4746-a958-1f21f32f0805@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
 <rHYOu1rSW3Iy9CNsYpRuD7hrvUGLmpi0Rutk9GZ9R4A=.750e81f8-c9e3-4746-a958-1f21f32f0805@github.com>
Message-ID: <rYakfFq4-q_24ENg0rzIfrkGNGaB9QfWj7_EkPe-weQ=.25d650ef-fed3-4c7c-90d8-2bfabad0c96b@github.com>

On Wed, 18 Sep 2024 16:53:53 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > > 
> > > 
> > > Nomenclature is suggested by Paul.
> > 
> > 
> > @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> 
> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.

Ok. I suppose these methods could eventually be moved to `java.lang.Math` or some other `java.lang` class, when the VectorAPI goes out of incubator mode?

I feel like these saturating operations, and also the unsigned ops could find a more wider use, away from (explicit) vector usage. For example, the saturating operations are nice because they prevent overflows, and in some cases that would be very nice to have readily available.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2360099389

From jbhateja at openjdk.org  Thu Sep 19 06:44:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 06:44:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v16]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <u29L2HUoBXqFCTlQTX7PrLw8hBhUCb-asHdfuh9Ahn4=.3a631ca5-1cbb-4a1b-a5a0-ee1190cc87e4@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Tests for newly added VectorMath.* operations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/f81b2525..bc08bab5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=14-15

  Stats: 331 lines in 13 files changed: 282 ins; 44 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Sep 19 06:44:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 06:44:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
Message-ID: <jpi78uoEpPROCs4CZdyTYkn3tCMq4goc085eXZODUkg=.e7af9403-4f9e-43fc-a168-f8ebbbf45fa3@github.com>

On Wed, 18 Sep 2024 14:22:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > > Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests? `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > 
> > 
> > Nomenclature is suggested by Paul.
> 
> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> 
> > We have sufficient test coverage of these APIs in JTREG tests.
> 
> @jatin-bhateja I can't see any dedicated JTREG tests to the `VectorMath` methods. I only see the VectorAPI tests. Can you point me to the `VectorMath` tests? I'd like to review them.

Hi @eme64 , @PaulSandoz  
Yes dedicated test for each of newly added VectorMath operation is justified here.

Thanks, let me know if there are other comments.

 

> > > > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > > > 
> > > > 
> > > > Nomenclature is suggested by Paul.
> > > 
> > > 
> > > @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> > 
> > 
> > It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
> 
> Ok. I suppose these methods could eventually be moved to `java.lang.Math` or some other `java.lang` class, when the VectorAPI goes out of incubator mode?
> 
> I feel like these saturating operations, and also the unsigned ops could find a more wider use, away from (explicit) vector usage. For example, the saturating operations are nice because they prevent overflows, and in some cases that would be very nice to have readily available.

Hi @eme64 , yes that what our extended plan is, for this patch we want to restrict its use to VectorAPI. 

> > > Do we have tests for the publically exposed methods in this new file? Or are they only implicitly tested through the VectorAPI, and its tests? `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java`
> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > 
> > 
> > Nomenclature is suggested by Paul.
> 
> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> 
> > We have sufficient test coverage of these APIs in JTREG tests.
> 
> @jatin-bhateja I can't see any dedicated JTREG tests to the `VectorMath` methods. I only see the VectorAPI tests. Can you point me to the `VectorMath` tests? I'd like to review them.

@eme64 , @PaulSandoz , I agree that explicit test for all newly added VectorMath operation for all integral types is justified here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2360118143

From jbhateja at openjdk.org  Thu Sep 19 06:53:15 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 06:53:15 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v17]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <-L7RYBQd-Q6zLkv5GKU0PDM2SZ-jdm1zAk1VRedDgyM=.c712848d-145b-4ecd-af2f-1a811832559d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Tuning extra spaces.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/bc08bab5..eb2960a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=15-16

  Stats: 38 lines in 1 file changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Sep 19 06:55:45 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 06:55:45 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <jpi78uoEpPROCs4CZdyTYkn3tCMq4goc085eXZODUkg=.e7af9403-4f9e-43fc-a168-f8ebbbf45fa3@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
 <jpi78uoEpPROCs4CZdyTYkn3tCMq4goc085eXZODUkg=.e7af9403-4f9e-43fc-a168-f8ebbbf45fa3@github.com>
Message-ID: <ZzJS5Y498bvYlV0TaXvvQJQbAcaQkiPriyeZBRiwzJk=.9c767b84-413c-4aeb-b253-226bcf93ba34@github.com>

On Thu, 19 Sep 2024 06:41:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
> > > > 
> > > > 
> > > > Nomenclature is suggested by Paul.
> > > 
> > > 
> > > @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
> > 
> > 
> > It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
> 
> Ok. I suppose these methods could eventually be moved to `java.lang.Math` or some other `java.lang` class, when the VectorAPI goes out of incubator mode?
> 
> I feel like these saturating operations, and also the unsigned ops could find a more wider use, away from (explicit) vector usage. For example, the saturating operations are nice because they prevent overflows, and in some cases that would be very nice to have readily available.

Hi @eme64 , as per @PaulSandoz  and @jddarcy we should wait till Valhalla preview to add full blown unsigned value type and associated operations, for the time being restricting the scope of these new operations to VectorAPI.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2360137469

From jbhateja at openjdk.org  Thu Sep 19 07:10:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 07:10:38 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v3]
In-Reply-To: <ejjSF36eH_T1oSpZTNgdcE-ayvxalBb6U0brArvq4K4=.642fa6e6-e424-4f9c-ad74-3b752241547c@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <ejjSF36eH_T1oSpZTNgdcE-ayvxalBb6U0brArvq4K4=.642fa6e6-e424-4f9c-ad74-3b752241547c@github.com>
Message-ID: <-SvKZpGY6NbQyh2PnmV5--a8f4oKdSq3VQKV2siSawg=.c812df74-12d4-428b-a7f9-5b1945cdae39@github.com>

On Wed, 18 Sep 2024 17:00:30 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>> 
>> Summary of changes is as follows:
>>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>> 
>> For the following source:
>> 
>> 
>>     public void test() {
>>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>>             index.selectFrom(inpvect).intoArray(byteres, j);
>>         }
>>     }
>> 
>> 
>> The code generated for inner main now looks as follows:
>> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>>   0x00007f40d02274d0:   movslq %ebx,%r13
>>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>>   0x00007f40d022751f:   add    $0x40,%ebx
>>   0x00007f40d0227522:   cmp    %r8d,%ebx
>>   0x00007f40d0227525:   jl     0x00007f40d02274d0
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change method name

src/hotspot/share/opto/vectorIntrinsics.cpp line 772:

> 770: 
> 771:   if (elem_klass == nullptr || shuffle_klass == nullptr || shuffle->is_top() || vlen == nullptr) {
> 772:     return false; // dead code

Why dead code  in comment ? this is a failed intrinsification condition.

src/hotspot/share/opto/vectorIntrinsics.cpp line 776:

> 774:   if (!vlen->is_con() || shuffle_klass->const_oop() == nullptr) {
> 775:     return false; // not enough info for intrinsification
> 776:   }

Why don't you club it with above conditions to be consistent with other inline expanders ?

src/hotspot/share/opto/vectorIntrinsics.cpp line 790:

> 788:   // Shuffles use byte array based backing storage
> 789:   BasicType shuffle_bt = T_BYTE;
> 790: 

No need a of new line b/w 789 and 791

src/hotspot/share/opto/vectorIntrinsics.cpp line 793:

> 791:   if (!arch_supports_vector(Op_AndV, num_elem, shuffle_bt, VecMaskNotUsed) ||
> 792:       !arch_supports_vector(Op_Replicate, num_elem, shuffle_bt, VecMaskNotUsed)) {
> 793:     return false;

You should emit proper intrinsification failure message here.

src/hotspot/share/opto/vectorIntrinsics.cpp line 805:

> 803:   const TypeVect* vt  = TypeVect::make(shuffle_bt, num_elem);
> 804:   const Type* shuffle_type_bt = Type::get_const_basic_type(shuffle_bt);
> 805: 

No need of a blank line here.

src/hotspot/share/opto/vectorIntrinsics.cpp line 808:

> 806:   Node* mod_mask = gvn().makecon(TypeInt::make(num_elem-1));
> 807:   Node* bcast_mod_mask  = gvn().transform(VectorNode::scalar2vector(mod_mask, num_elem, shuffle_type_bt));
> 808: 

Remove redundant new line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766272449
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766273205
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766273880
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766274718
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766275107
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766275345

From jbhateja at openjdk.org  Thu Sep 19 07:32:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 07:32:38 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v3]
In-Reply-To: <ejjSF36eH_T1oSpZTNgdcE-ayvxalBb6U0brArvq4K4=.642fa6e6-e424-4f9c-ad74-3b752241547c@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <ejjSF36eH_T1oSpZTNgdcE-ayvxalBb6U0brArvq4K4=.642fa6e6-e424-4f9c-ad74-3b752241547c@github.com>
Message-ID: <2pPJKmEHM24iStw8Xv2IQ08Xrp7Ag3P2_9yEzsS4nOw=.49f3554d-0917-40ff-8824-d8719c3d271f@github.com>

On Wed, 18 Sep 2024 17:00:30 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>> 
>> Summary of changes is as follows:
>>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>> 
>> For the following source:
>> 
>> 
>>     public void test() {
>>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>>             index.selectFrom(inpvect).intoArray(byteres, j);
>>         }
>>     }
>> 
>> 
>> The code generated for inner main now looks as follows:
>> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>>   0x00007f40d02274d0:   movslq %ebx,%r13
>>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>>   0x00007f40d022751f:   add    $0x40,%ebx
>>   0x00007f40d0227522:   cmp    %r8d,%ebx
>>   0x00007f40d0227525:   jl     0x00007f40d02274d0
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change method name

Hi @sviswa7 , some comments, overall patch looks good to me.

Best Regards,
Jatin

src/hotspot/share/opto/vectorIntrinsics.cpp line 2120:

> 2118: 
> 2119:   if (vector_klass == nullptr  || elem_klass == nullptr || vlen == nullptr) {
> 2120:     return false; // dead code

Why dead code in comments ?

src/hotspot/share/opto/vectorIntrinsics.cpp line 2129:

> 2127:                     NodeClassNames[argument(2)->Opcode()],
> 2128:                     NodeClassNames[argument(3)->Opcode()]);
> 2129:     return false; // not enough info for intrinsification

Please club this with above condition to be consistent with other inline expanders.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2141:

> 2139:   }
> 2140:   BasicType elem_bt = elem_type->basic_type();
> 2141: 

Remove new line.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2144:

> 2142:   int num_elem = vlen->get_con();
> 2143:   if ((num_elem < 4) || !is_power_of_2(num_elem)) {
> 2144:     log_if_needed("  ** vlen < 4 or not power of two=%d", num_elem);

Will num_elem < 4  not be handled by L2149 since we have an implementation limitation to support less than 32-bit shuffle / masks.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2171:

> 2169:     use_predicate = false;
> 2170:     if(!is_masked_op ||
> 2171:        (!arch_supports_vector(Op_VectorRearrange, num_elem, elem_bt, VecMaskNotUsed) ||

Suggestion:

       (!arch_supports_vector(Op_VectorRearrange, num_elem, elem_bt, VecMaskUseLoad) ||

src/hotspot/share/opto/vectorIntrinsics.cpp line 2188:

> 2186: 
> 2187:   if (v1 == nullptr || v2 == nullptr) {
> 2188:     return false; // operand unboxing failed

To be consistent with other expanders please emit proper error for unboxing failure like on following line.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L426

src/hotspot/share/opto/vectorIntrinsics.cpp line 2197:

> 2195:     mask = unbox_vector(argument(6), mbox_type, elem_bt, num_elem);
> 2196:     if (mask == nullptr) {
> 2197:       log_if_needed("  ** not supported: op=selectFrom vlen=%d etype=%s is_masked_op=1",

Error should an unboxing failure here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20634#pullrequestreview-2314643808
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766277056
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766277739
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766278169
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766297640
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766292679
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766303620
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1766304688

From mbaesken at openjdk.org  Thu Sep 19 07:46:04 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 19 Sep 2024 07:46:04 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
Message-ID: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>

Windows Server 2025 will be releases in a few months.
The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
(currently Windows server 2022 is printed , that is wrong)

The build numbers of some recent previews documented here
https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
are 26080 and 26085 (final release version will most likely be a bit higher).

-------------

Commit messages:
 - JDK-8340387

Changes: https://git.openjdk.org/jdk/pull/21082/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21082&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340387
  Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21082/head:pull/21082

PR: https://git.openjdk.org/jdk/pull/21082

From viktor.klang at oracle.com  Thu Sep 19 09:30:46 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 19 Sep 2024 09:30:46 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
 <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>
Message-ID: <MW4PR10MB57741DBB8EC8562AD2224B1EFF632@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Anthony,

Bear with me for a moment,

in the same vein as there's nothing which enforces equals(?) or hashCode() to be conformant to their specs, or any interface-implementation for that matter, I don't see how we could make any stronger enforcement of Gatherers.

>My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.

Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather). Ultimately, it all boils down to specification?if an equals(?)-method implementation leads to surprising behavior when used with a collection, one typically needs to first ensure that the equals(?)-method conforms to its expected specification before one can presume that the collection has a bug.

For the "just work"?scenario, one can only make claims about things which have been proven. So in this case, what tests have passed for the implementation in question?

>Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction.

java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?

> "protecting the users from being given non-reusable Gatherers"

Think of it more like increasing the odds that users are given spec-conformant Gatherers.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Anthony Vanelverdinghe <dev at anthonyv.be>
Sent: Wednesday, 18 September 2024 18:27
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback

Hi Viktor

Let me start with a question: is the requirement (a) "a Gatherer SHOULD be reusable", or (b) "a Gatherer MUST be reusable"?
As of today the specification says (b), whereas the implementation matches (a).

In case of (a), I propose to align the specification to allow for compliant, non-reusable Gatherers.

In case of (b), I propose to align the implementation to enforce compliance. Something like:
(1) invoke `initializer()` twice, giving `i1` and `i2`. Discard `i1` and invoke `i2` twice, giving `state1` and `state2`.
(2) invoke `finisher()` twice, giving `f1` and `f2`. Discard `f1` and invoke `f2` twice, the first time with `state1` and a dummy Downstream, the second time with the actual final state, i.e. `state2` after all elements were integrated, and the actual Downstream.
Then backport this change to JDK 23 & 22 and/or do another round of preview in JDK 24.
I'm confident that enforcing compliance would result in significant amounts of feedback questioning the requirement.

My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.

Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction. You say:

> And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.

so I'd guess the rationale is "protecting the users from being given non-reusable Gatherers".
However, I can't readily think of a situation where this would be essential.
If a user creates a Gatherer by invoking a factory method, the factory method can specify whether its result is reusable.
And if a user is given a Gatherer as a method argument, and they need the Gatherer to be reusable, they could change the parameter to a `Supplier<Gatherer>` instead.

> >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
>
> There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.

We agree, just that I'd provide 2 factory methods, `concat(Stream<T>)` (non-reusable) and `append(List<T>)` (reusable), whereas you'd provide a 2-in-1 `concat(Supplier<Stream<T>>)`.

Kind regards, Anthony

September 12, 2024 at 11:55 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> Hi Anthony
>
> Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.
>
> >While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
>
> To me, this is governed by the following parts of the Gatherer specification https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html :
>
> "Each invocation of initializer() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer() ,integrator() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator() ,combiner() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner() , and finisher() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher()  must return a semantically identical result."
>
> and
>
> "Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstreamGatherer.Downstream https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html PREVIEW https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream  for longer than the invocation duration of the method which they are passed to."
>
> And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
>
> For Stream, the assumption is that they are NOT reusable at all.
> For Gatherer, I think the only reasonable assumption is that they are reusable.
>
> >In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?
>
> Not necessarily, if the factory method **consumes** the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.
>
> >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
>
> There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
>
> >As another example, take Gunnar Morling's zip Gatherers:
>
> I don't see how Gatherers like this could be made reusable, or why that would even be desirable.
>
> Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().
>
> >My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
>
> My apologies, I misunderstood. To me, the operation you describe is called `inject`.
> Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.
>
> Thanks again for the great questions and conversation, it's valuable!
> Cheers,
>
> ?
>
> **Viktor Klang**
> Software Architect, Java Platform Group
>
> Oracle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240919/d87a0a31/attachment-0001.htm>

From mullan at openjdk.org  Thu Sep 19 11:47:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 19 Sep 2024 11:47:37 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <Ce0xsi9ecGi48Qxcu4fWSM1vweRNQhWy9Vz00Dywql4=.3b86fe3b-e556-476d-a9e1-57a1194af17d@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2315289461

From jvernee at openjdk.org  Thu Sep 19 12:20:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Sep 2024 12:20:13 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v6]
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - use resolve_global_jobject on s390
 - Merge branch 'master' into LoadVMTraget
 - remove PC save/restore on s390
 - use fatal()
 - add RISC-V as target platform
 - Adjust ppc & RISC-V code
 - Add s390 changes
 - Merge branch 'master' into LoadVMTraget
 - Don't save/restore LR/CR + resolve_jobject on s390
 - eyeball other platforms
 - ... and 14 more: https://git.openjdk.org/jdk/compare/2faf8b8d...b703b162

-------------

Changes: https://git.openjdk.org/jdk/pull/20479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20479&range=05
  Stats: 333 lines in 23 files changed: 255 ins; 26 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/20479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20479/head:pull/20479

PR: https://git.openjdk.org/jdk/pull/20479

From jvernee at openjdk.org  Thu Sep 19 12:20:14 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Sep 2024 12:20:14 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v5]
In-Reply-To: <NW7RnSebixCDMAy1OxvxA0z5_eu65p7JIkUk2Rn1o0s=.d54719e4-a3a0-4a66-b364-4fc7b938734b@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <9Lc9Ej1toiiI8QFYXndprsPo4l-g20XWPDw5g9l36Fk=.091f48aa-5559-4862-8968-e4283d3fa728@github.com>
 <NW7RnSebixCDMAy1OxvxA0z5_eu65p7JIkUk2Rn1o0s=.d54719e4-a3a0-4a66-b364-4fc7b938734b@github.com>
Message-ID: <vGjzLryBdDtmj6g9W8AAPt8NSbwoefdJC4QY0Fqce3U=.d5704c6c-4093-47d9-8a05-c4e2c82162d0@github.com>

On Thu, 19 Sep 2024 05:03:50 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove PC save/restore on s390
>
> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3063:
> 
>> 3061:     address start = __ pc();
>> 3062: 
>> 3063:     __ resolve_jobject(Z_ARG1, Z_tmp_1, Z_tmp_2);
> 
> @JornVernee is it possible to rebase to head stream ? If there are no issue on other archs :-) 
> 
> I have implemented `resolve_global_jobject` method for s390x and merged changes to head stream with PR https://github.com/openjdk/jdk/pull/20986. Once rebased you can push below change. 
> 
> Suggestion:
> 
>     __ resolve_global_jobject(Z_ARG1, Z_tmp_1, Z_tmp_2);

I've switched s390 to use `resolve_global_jobject` as well now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1766727056

From mcimadamore at openjdk.org  Thu Sep 19 12:34:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 12:34:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods
In-Reply-To: <XH6kvzP6J5_bzVziFnygM0mV8gc4M9WP9yc4VOT5H1E=.6c72b5fc-2bcb-44f4-b6b5-05a24a7c933d@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <XH6kvzP6J5_bzVziFnygM0mV8gc4M9WP9yc4VOT5H1E=.6c72b5fc-2bcb-44f4-b6b5-05a24a7c933d@github.com>
Message-ID: <3Nt65-I0eETs2YZZ3Pr3Tq6NmPSYCnmXdNONuuht9Xw=.2dbb43c3-a26d-445b-a50d-b2e798d22454@github.com>

On Thu, 19 Sep 2024 02:59:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As I wrote in the CSR request for the JEP:
> 
> > I think each method that is restricted and/or caller-sensitive should specify what happens when called when there is no caller context. We should use `AccessibleObject::canAccess` as an exemplar here:
> > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/reflect/AccessibleObject.html#canAccess(java.lang.Object)
> > I have no doubt other caller-sensitive methods have failed to do this to date, but that should be fixed.
> 
> This has to be mentioned in e.g. the javadoc for `System.loadLibrary`.

I don't disagree that the javadoc for `System::loadLibrary` is lacking. But we're conflating two aspects here. One is to say which module is used to perform the "enable native access check". And I think such a specification belongs to where we talk about _all_ restricted methods (as done in this PR). I tend to view native access enablement as orthogonal to the specification of "hat does the method do?". But perhaps that ship has sailed when we added `@throws IllegalCallerException` on all restricted methods, so perhaps it is part of the method contract after all...

Then there's the question of: JNI libraries are associated with class loaders. The class loader affected by a `System::loadLibrary` is typically derived from the class loader of the caller class. But what if there's no "caller class" ? This is, IMHO, something that `System::loadLibrary`'s javadoc should address (as this is interesting behavior re. what this method does). And I claim that this is outside the scope of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2360857418

From mcimadamore at openjdk.org  Thu Sep 19 13:59:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 13:59:30 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v2]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Move restricted method page to `java.lang`
  Update restricted method page

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/7ce83442..0d7d0f9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=00-01

  Stats: 125 lines in 3 files changed: 53 ins; 71 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From mcimadamore at openjdk.org  Thu Sep 19 14:08:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 14:08:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v2]
In-Reply-To: <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
Message-ID: <9BV3Xsr1BCQOX5a6DCZJzXgbDEJumzkZW9XRmTZNSWM=.822d29f0-bd39-4eaa-9b10-7bc5347fa50f@github.com>

On Thu, 19 Sep 2024 13:59:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move restricted method page to `java.lang`
>   Update restricted method page

src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 31:

> 29: </head>
> 30: <body>
> 31: <h1 id="restricted">Restricted methods</h1>

I've kept the text more general. I took the liberty to use (and tweak) some text in here:
https://cr.openjdk.org/~iris/se/23/spec/fr/java-se-23-fr-spec/

The example is now gone - while we could still provide some example, I believe it's hard not to get too drawn into specifics. I think stating that these methods can violate integrity is probably enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1766904504

From mcimadamore at openjdk.org  Thu Sep 19 14:11:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 14:11:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v2]
In-Reply-To: <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
Message-ID: <tY1gKsqmnCiAvyhg-3gwZU7dRIKwlManOpqqqCdCBx8=.91109f12-2bf7-4c75-b8ce-939a56b6578f@github.com>

On Thu, 19 Sep 2024 13:59:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move restricted method page to `java.lang`
>   Update restricted method page

src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 41:

> 39:     done either via implementation-specific command line options or programmatically, e.g.
> 40:     by calling <a href="../../ModuleLayer.Controller.html#enableNativeAccess(java.lang.Module)"><code>ModuleLayer.Controller.enableNativeAccess(java.lang.Module)</code></a>.</p>
> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,

IMHO, having this text here is better than copy and paste a similar version of this text in 14 (!!) places. That's why we added the `@Restricted` annotation, to make sure that uniform javadoc is generated for all restricted methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1766909046

From redestad at openjdk.org  Thu Sep 19 14:15:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Sep 2024 14:15:21 GMT
Subject: RFR: 8340456: Reduce overhead of proxying Object methods in
 ProxyGenerator
Message-ID: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>

This PR changes proxy code gen to avoid generating `Class.forName("java.lang.Object")`, instead emitting an ldc for the class literal, `ldc(CD_Object)`, java code equivalent `Object.class`. 

More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from `InvokerBytecodeGenerator.isStaticallyInvocable`, but just addressing the `Object` methods gets rid of most `Class.forName` emits. It's not terribly important for throughput performance since these are called in the generated `clinit`, so getting a quick win with few additional checks is a good starting point.

Added a few unrelated minor refactors/improvements, guided by diagnostic runs of the now fixed microbenchmark.

-------------

Commit messages:
 - Merge branch 'master' into proxy_codeClass_ProxyPerf
 - Minor improvements
 - Refactor
 - Tune warmup and measurement time for ProxyGeneratorBench
 - rename and improve Proxy micros
 - Fix ProxyPerf microbenchmark and micro-optimize codeClassForName

Changes: https://git.openjdk.org/jdk/pull/21090/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340456
  Stats: 327 lines in 4 files changed: 146 ins; 166 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21090/head:pull/21090

PR: https://git.openjdk.org/jdk/pull/21090

From liach at openjdk.org  Thu Sep 19 14:17:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 14:17:44 GMT
Subject: RFR: 8340456: Reduce overhead of proxying Object methods in
 ProxyGenerator
In-Reply-To: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
References: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
Message-ID: <4h0b2GxQC4CKKZv0gHH0ZwdOTkSGwC2KesuuqqyEwWg=.0f2750bb-c0e0-40e0-bdb0-f41f808695c1@github.com>

On Thu, 19 Sep 2024 14:08:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR changes proxy code gen to avoid generating `Class.forName("java.lang.Object")`, instead emitting an ldc for the class literal, `ldc(CD_Object)`, java code equivalent `Object.class`. 
> 
> More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from `InvokerBytecodeGenerator.isStaticallyInvocable`, but just addressing the `Object` methods gets rid of most `Class.forName` emits. It's not terribly important for throughput performance since these are called in the generated `clinit`, so getting a quick win with few additional checks is a good starting point.
> 
> Added a few unrelated minor refactors/improvements, guided by diagnostic runs of the now fixed microbenchmark.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 833:

> 831:                 cob.ldc(objectCE);
> 832:             } else {
> 833:                 cob.ldc(cl.getName())

This `Class.forName` is only necessary in a very small number of cases, namely when the overridden interface method has an unaccessible parameter type, usually a package-private type not accessible to the implementing class. Maybe we can always directly ldc if the class is `public`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21090#discussion_r1766920897

From redestad at openjdk.org  Thu Sep 19 14:48:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Sep 2024 14:48:36 GMT
Subject: RFR: 8340456: Reduce overhead of proxying Object methods in
 ProxyGenerator
In-Reply-To: <4h0b2GxQC4CKKZv0gHH0ZwdOTkSGwC2KesuuqqyEwWg=.0f2750bb-c0e0-40e0-bdb0-f41f808695c1@github.com>
References: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
 <4h0b2GxQC4CKKZv0gHH0ZwdOTkSGwC2KesuuqqyEwWg=.0f2750bb-c0e0-40e0-bdb0-f41f808695c1@github.com>
Message-ID: <m3Y7NEkTl1vpTw-UevGbbCfq1emubVbH6RwcalRP3TY=.e554597c-3b66-4542-9ece-a7093d58da84@github.com>

On Thu, 19 Sep 2024 14:14:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR changes proxy code gen to avoid generating `Class.forName("java.lang.Object")`, instead emitting an ldc for the class literal, `ldc(CD_Object)`, java code equivalent `Object.class`. 
>> 
>> More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from `InvokerBytecodeGenerator.isStaticallyInvocable`, but just addressing the `Object` methods gets rid of most `Class.forName` emits. It's not terribly important for throughput performance since these are called in the generated `clinit`, so getting a quick win with few additional checks is a good starting point.
>> 
>> Added a few unrelated minor refactors/improvements, guided by diagnostic runs of the now fixed microbenchmark.
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 833:
> 
>> 831:                 cob.ldc(objectCE);
>> 832:             } else {
>> 833:                 cob.ldc(cl.getName())
> 
> This `Class.forName` is only necessary in a very small number of cases, namely when the overridden interface method has an unaccessible parameter type, usually a package-private type not accessible to the implementing class. Maybe we can always directly ldc if the class is `public`.

Yeah, I'm just not sure what rules are quite right here. Wouldn't want to inadvertently regress this again, and not sure we have tests for all eventualities, so I started this off with the most conservative yet most beneficial improvement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21090#discussion_r1766973606

From liach at openjdk.org  Thu Sep 19 16:10:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 16:10:41 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <9w0vDw_SlDjmvMMxth9mj5SzdvXmoYlHxB31RnOtZ88=.36bd09a9-181f-42d9-8eaa-fe2e34e3e19f@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

I think I can add a benchmark to measure first-time insertion cost with already-hashed ClassDesc and internal name/array descriptors.

For your request of a table for smaller power exponents, I wish to delay it a bit, maybe in another patch - this patch is almost exclusively functional additions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2361435817

From jlu at openjdk.org  Thu Sep 19 16:21:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 16:21:43 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <8vbEWScGpsDLSyqFV_wVIsJOGtYFHIvXVGOqh5n0pUA=.3faedb46-eed4-43b9-8ad8-435ba8f320e2@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21046#issuecomment-2361455381

From jlu at openjdk.org  Thu Sep 19 16:21:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 16:21:43 GMT
Subject: Integrated: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <4Jni6WhPBSkweDV1MOhkafn9oCwETZ4Ly2Z5qmr9ZB4=.5c7f9170-82a1-478f-85bb-1f6f60b945bb@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

This pull request has now been integrated.

Changeset: 5f3e7aa8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f3e7aa83348edafb83480ce67d0c58c46e11b24
Stats:     19 lines in 7 files changed: 0 ins; 1 del; 18 mod

8339735: Remove references to Applet in core-libs/security APIs

Reviewed-by: coffeys, naoto, iris, rriggs, lancea, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/21046

From nbenalla at openjdk.org  Thu Sep 19 16:38:54 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 19 Sep 2024 16:38:54 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Change "found" to "should be" in the error messages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - avoid using `continue`, fix mistake in last commit
 - extend SinceChecker to now skip some packages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Skip over files and packages that aren't found
 - Move the tests to module/module_name directory for clearer naming
 - (C)
 - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e

-------------

Changes: https://git.openjdk.org/jdk/pull/18934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=13
  Stats: 967 lines in 3 files changed: 965 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From nbenalla at openjdk.org  Thu Sep 19 16:43:38 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 19 Sep 2024 16:43:38 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
Message-ID: <MxkO5-gLMa6N_nKI_n1-Uc3hPcRupZ3Js-l3M2Fw5IY=.1da5ec89-6757-4c57-98ad-6baef23bae6e@github.com>

On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Skip over files and packages that aren't found
>  - Move the tests to module/module_name directory for clearer naming
>  - (C)
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e

I performed a merge and a tiny change to the error message by the test.
The major changes since the last review are that I now skip packages if they are not found, and I added an exclude list to skip certain packages if we wish to do so.

Here is an example of the error output of the tool 

STDERR:
src/java.base/java/lang/classfile/TypeKind.java:73 field: java.lang.classfile.TypeKind:BOOLEAN: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:80 field: java.lang.classfile.TypeKind:BYTE: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:87 field: java.lang.classfile.TypeKind:CHAR: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:94 field: java.lang.classfile.TypeKind:SHORT: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:99 field: java.lang.classfile.TypeKind:INT: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:103 field: java.lang.classfile.TypeKind:LONG: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:107 field: java.lang.classfile.TypeKind:FLOAT: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:111 field: java.lang.classfile.TypeKind:DOUBLE: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:117 field: java.lang.classfile.TypeKind:REFERENCE: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:125 field: java.lang.classfile.TypeKind:VOID: `@since` version: 22; should be: 24
src/java.base/java/lang/classfile/TypeKind.java:143 method: java.lang.constant.ClassDesc java.lang.classfile.TypeKind.upperBound(): `@since` version: 22; should be: 24
java.lang.Exception: The `@since` checker found 64 problems
        at SinceChecker.checkModule(SinceChecker.java:265)
        at SinceChecker.main(SinceChecker.java:126)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2361549329

From liach at openjdk.org  Thu Sep 19 17:14:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 17:14:07 GMT
Subject: RFR: 8339198: Remove tag field from AbstractPoolEntry
Message-ID: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>

The `tag` field in `AbstractPoolEntry` is redundant, as it's always of the same value for each subtype. This is now replaced with an override. This can reduce the footprint of the entries..

The removal of `hash` was considered but withdrawn; in part because hash computations are heavy; in c2 things as simple as identity hash code are better stored in object fields for performance.

-------------

Commit messages:
 - 8339198: Remove tag field from AbstractPoolEntry

Changes: https://git.openjdk.org/jdk/pull/21093/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339198
  Stats: 140 lines in 1 file changed: 97 ins; 4 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/21093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21093/head:pull/21093

PR: https://git.openjdk.org/jdk/pull/21093

From jvernee at openjdk.org  Thu Sep 19 17:31:35 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Sep 2024 17:31:35 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v2]
In-Reply-To: <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
Message-ID: <m_1GRtyM32t0wgl1FRtjgBLDsNe4KfUCLb8PU2RD2YA=.0bdfb745-2f7b-42ad-990d-858b6c659e09@github.com>

On Thu, 19 Sep 2024 13:59:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move restricted method page to `java.lang`
>   Update restricted method page

Looks good!

src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 43:

> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,
> 42:     or from an <a href="../Linker.html#upcallStub(java.lang.invoke.MethodHandle,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Arena,java.lang.foreign.Linker.Option...)">upcall stub</a>
> 43:     and there is no caller class on the stack, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>

> there is no caller class on the stack

I feel like this could be a little more elaborate. I'm not sure if it's clear enough which 'stack' this is talking about, and what it means for a class to be on the stack, considering a reader who doesn't know that the caller of a caller-sensitive method is determined through a stack walk.

Maybe this could be a vague blanket statement instead, like:

Suggestion:

    and a Java caller can not be determined, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>


Unfortunately, there doesn't seem to be a central place we can link to that describes how a caller for a caller sensitive method is determined, and in which cases it can not be determined (because there is no caller), which we could link to from here. There's a short discussion of caller sensitive methods [here](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#callsens), but it doesn't explain how the caller is determined.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2316287230
PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1767316787

From aefimov at openjdk.org  Thu Sep 19 17:55:13 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 19 Sep 2024 17:55:13 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Track unfulfilled timeouts during UDP queries.
  Update exceptions handling.
  Update TCP client to use nano time source.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/bdc79d42..70922207

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20892&range=06-07

  Stats: 84 lines in 1 file changed: 55 ins; 6 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

PR: https://git.openjdk.org/jdk/pull/20892

From aefimov at openjdk.org  Thu Sep 19 17:55:13 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 19 Sep 2024 17:55:13 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v5]
In-Reply-To: <94p0hdl62YchjVI6-UNZ3Vp1SFSWAHVC348whuK_f0o=.8a831b98-7046-4786-912b-870b6085575a@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <9QZmH6rNznV9crAm0920QCu3dQfGaO3uVJcCrrdx42A=.4104ba95-7d39-4c29-8b86-166dc00dcb3b@github.com>
 <4RyICTVeUA3B29_0gOpZPpO46Q2m9TErgVYzMjHsrSE=.56b2caf6-ee64-40bf-9e2d-4a736db8d60a@github.com>
 <OZMfdb8jjzlr6jtu_f4QXdy_Ja475EZlisZw2Or8K70=.7b76302f-33ac-4bc6-88e3-11525aed64fc@github.com>
 <noE9nM5cAdGeNDakUS56DfRC6-wkUKBybPThBHWuMq4=.f5ab0566-c6f7-4c8d-9d7c-02b5a5a8bb8e@github.com>
 <SfTbgnR78dBqBXHsEuhm4dyZkeb1nT4GO4Qwnj91Fq4=.736276ff-c45f-4f8c-95b5-2d8a52aa68a0@github.com>
 <8gQI8QaHUU8Je6KG15-k-7IwYOw1GNQCZxkJ5UDTMVI=.ba34290b-92eb-4d60-af03-0d8c804c04e4@github.com>
 <Ma_5S4QCa5-k6jNnOQVg2LUXoqQCXg08d6MfNp_bC28=.19b9a405-c7fe-4225-b020-07d06aee35f4@github.com>
 <94p0hdl62YchjVI6-UNZ3Vp1SFSWAHVC348whuK_f0o=.8a831b98-7046-4786-912b-870b6085575a@github.com>
Message-ID: <SA2NO9mHGtA7U1BfghqXCidg1L7J3KnhMuo10Of7PdE=.a40e9303-e3bb-45ff-92d0-fb53ccb20c3a@github.com>

On Wed, 11 Sep 2024 16:27:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 2 time  is not too high,
>> I have presented, in the comment, a failures with the elapsed time is almost twice the expected time
>> where the elapsed time is 14229 !! which is approx 1.84 * expected timeout
>
> @msheppar with the latest proposed change to set MIN_TIMEOUT to 0, then I believe the `@implNote` you suggested is no longer needed.

To address issue `#3` the UDP part of the `DnsClient` implementation has been changed to track the timeout left for each server for the unfulfilled timeout left for each server. An additional retry attempt was added to compensate for left timeouts.
The exception handling has been also updated to save observed exceptions as suppressed.
Also, the TCP part of the `DnsClient` has been changed to use nano time source for timeout calculations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1767352955

From liach at openjdk.org  Thu Sep 19 18:02:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 18:02:07 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v4]
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <Lkq8nZbd4uxxa0wmRpuCmEqPHKwvJ1D_ttwld32MXN4=.4ff64632-a2e4-4919-8696-6e581940f22b@github.com>

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Fresh creation bench
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Fix build
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Buggy 2nd attempt - crashes hotspot
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - More conflicts
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - ... and 7 more: https://git.openjdk.org/jdk/compare/3bb8de31...eed09345

-------------

Changes: https://git.openjdk.org/jdk/pull/20667/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20667&range=03
  Stats: 689 lines in 7 files changed: 594 ins; 42 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/20667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20667/head:pull/20667

PR: https://git.openjdk.org/jdk/pull/20667

From liach at openjdk.org  Thu Sep 19 18:04:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 18:04:38 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v3]
In-Reply-To: <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <9OSs696Dx-AcojqMuMtPl9MA_MiJSrvHAcQq_NCx2RE=.117e9eb8-e89f-49d2-b44b-6c343aa680b6@github.com>
Message-ID: <O5D8T1VUvRBeK-aCFicvlDejUoe6pVaU2acEr-BGf7I=.b416b230-d274-439b-bd2d-c3e39af163d9@github.com>

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Benchmark                                                       Mode  Cnt     Score     Error   Units      Score     Error   Units
ConstantPoolBuildingClassEntry.freshCreationWithDescs          thrpt    5   340.391  ?   0.607  ops/ms   351.801  ?   5.991  ops/ms
ConstantPoolBuildingClassEntry.freshCreationWithInternalNames  thrpt    5   408.762  ?   5.699  ops/ms   397.367  ?   1.516  ops/ms
ConstantPoolBuildingClassEntry.identicalLookup                 thrpt    5   641.875  ?   7.192  ops/ms  2202.179  ? 464.878  ops/ms
ConstantPoolBuildingClassEntry.internalNameLookup              thrpt    5  2054.220  ? 237.406  ops/ms  1476.090  ?  33.318  ops/ms
ConstantPoolBuildingClassEntry.nonIdenticalLookup              thrpt    5   645.414  ?  14.929  ops/ms  1811.743  ?  83.868  ops/ms
ConstantPoolBuildingClassEntry.oldStyleLookup                  thrpt    5   651.489  ?  10.941  ops/ms   529.306  ?   4.414  ops/ms


Latest benchmark results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2361845713

From redestad at openjdk.org  Thu Sep 19 18:35:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Sep 2024 18:35:44 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v4]
In-Reply-To: <Lkq8nZbd4uxxa0wmRpuCmEqPHKwvJ1D_ttwld32MXN4=.4ff64632-a2e4-4919-8696-6e581940f22b@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <Lkq8nZbd4uxxa0wmRpuCmEqPHKwvJ1D_ttwld32MXN4=.4ff64632-a2e4-4919-8696-6e581940f22b@github.com>
Message-ID: <Z4SlK7XwpWp08PkoexSk9ZoUsW2gMGxwntOyXVO4Y1U=.d20e9713-7b25-4a1e-805e-cae20f9ff65d@github.com>

On Thu, 19 Sep 2024 18:02:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Fresh creation bench
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3bb8de31...eed09345

LGTM

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20667#pullrequestreview-2316420990

From liach at openjdk.org  Thu Sep 19 18:35:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 18:35:45 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <YlkCCHtpzFl_5bWmdOKhTZeCKBX3dVAhfOJ97tquAv4=.5de0b836-8000-4d2e-8f51-8f60e3212c31@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <WSNFEvaB6MBD-WwCaz3jCX5T7RtL_P2Cbyj0t20nxmw=.ccf7face-e4d7-4f59-a593-b2e7bddab2f7@github.com>
 <vS3YGpvG6rGt4E9J2IszN42bOcBHstdsrm8EYltWAQE=.64c3b70c-4b2d-469a-a336-117fcca343fe@github.com>
 <UF3u0URpLrleBQpKktS3zUmkq4AUUjpC-LMXQGUtktk=.9b7098cd-a0de-4368-8807-3e296059af5b@github.com>
 <YlkCCHtpzFl_5bWmdOKhTZeCKBX3dVAhfOJ97tquAv4=.5de0b836-8000-4d2e-8f51-8f60e3212c31@github.com>
Message-ID: <6J_dCTaZ0zY8_-XmqhMf2P-aXug6VT34tjQ7cRkaGKY=.1e1fdef5-a6d8-4d0b-ae49-9cf8b5e64a64@github.com>

On Mon, 16 Sep 2024 19:11:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I measured in bytestacks and the clinit instructions reduced by about 2/3
>
> Yes, you have to pick and evaluate between two trade-offs here: a compact routine to compute the array, or a larger initializer which does less compute. Number of instructions executed in the interpreter is a diagnostic tool since if often hides costs that come from having to store, read, parse and manage bytecode - sometimes twice if this hits the default CDS archive. There's no definite answer, but generally the trend is towards compute getting cheaper and IO/memory getting (relatively) more expensive. So picking a larger representation to avoid some one-off compute might be the wrong trade-off.
> 
> (Note that this particular instance is probably negligible either way, I just don't want bytestacks instrumentation to put us down a path where we might ultimately end up worse off. Diagnostics needs to be verified with realistic wall clock measurements. When uncertain: go for simplicity.)

I will leave this hash computation mechanism whole as is; table initialization and small table optimizations can come in other patches later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1767398487

From liach at openjdk.org  Thu Sep 19 18:35:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 18:35:46 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v4]
In-Reply-To: <E30eLJFDyMZs0D3wryJJgjOUQnxKrr72YK3AWnk-wAs=.16bc530a-dc6b-4157-902b-5da0cdc6619a@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>
 <4r6JLOM2r7tytLhgb0m2YfbMWI1wsbIMM9AWE12vQ5k=.f65943fd-0732-4916-87c1-ebb356fe2129@github.com>
 <9wOdVQOrX_pTEkk8WbD6_MkBe4TUp0vvQqL72b7blas=.07bb7c4d-43e0-4d72-a5e3-9ea188b4801a@github.com>
 <reCOVWHfs5acjd0OQdTOa6JJMwfXgWcVIaohD4uWe6M=.2eec5211-4323-47a1-a147-d209fe8d2089@github.com>
 <E30eLJFDyMZs0D3wryJJgjOUQnxKrr72YK3AWnk-wAs=.16bc530a-dc6b-4157-902b-5da0cdc6619a@github.com>
Message-ID: <uadjhQwFuZJcDYPrQl2U9q_y8_FM63b97_yBTdpMN_8=.ff3494d9-4a39-49f8-b556-a8e21272438f@github.com>

On Thu, 22 Aug 2024 14:34:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Uh, I mean it's a class entry... and class file format prohibits primitives in class entries. I would deduce that information from the benchmark name.
>
> Yes, obvious in hind-sight, but comments are good to remind readers of context that might not be obvious at a glance or without paging in the full context.

Added a note in this benchmark; should suffice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1767397450

From liach at openjdk.org  Thu Sep 19 18:37:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 18:37:35 GMT
Subject: RFR: 8340456: Reduce overhead of proxying Object methods in
 ProxyGenerator
In-Reply-To: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
References: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
Message-ID: <y8jF56QKM-ovLElr11nvJMJ76LEJbJsFqdWOXkRhZHM=.19605a59-1d4c-488e-98c9-c830641c323d@github.com>

On Thu, 19 Sep 2024 14:08:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR changes proxy code gen to avoid generating `Class.forName("java.lang.Object")`, instead emitting an ldc for the class literal, `ldc(CD_Object)`, java code equivalent `Object.class`. 
> 
> More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from `InvokerBytecodeGenerator.isStaticallyInvocable`, but just addressing the `Object` methods gets rid of most `Class.forName` emits. It's not terribly important for throughput performance since these are called in the generated `clinit`, so getting a quick win with few additional checks is a good starting point.
> 
> Added a few unrelated minor refactors/improvements, guided by diagnostic runs of the now fixed microbenchmark.

Replacing Class.forName with ldc or even condy is an esoteric topic. We can dive into that later and pick up the obvious gains.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21090#pullrequestreview-2316431460

From dev at anthonyv.be  Thu Sep 19 18:57:02 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Thu, 19 Sep 2024 18:57:02 +0000
Subject: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB57741DBB8EC8562AD2224B1EFF632@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
 <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>
 <MW4PR10MB57741DBB8EC8562AD2224B1EFF632@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <46bc86380b39b14b20d3d1e589015594b15c1189@anthonyv.be>

Hi Viktor

> Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather).

The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.
This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".

> java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?

For `Stream` the package Javadoc has statements like "No storage. A stream is not a data structure" and "Possibly unbounded.", which is sufficient rationale to me.
For `Collector`, unless I'm missing something, it does not actually specify that it must be reusable, so it does not have to provide a rationale for it either. Even if I did miss something and reusability is implied from the specification: the question would likely never come up, because a Collector will in practice always be reusable anyway (read: I can't readily think of a sensible non-reusable Collector). This is unlike Gatherer, where some obvious use cases such as `concat` and `zip` exist and people like me wonder why such use cases are, apparently needlessly, prohibited by the Gatherer specification.

> Think of it more like increasing the odds that users are given spec-conformant Gatherers.

Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it? I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers. Gunnar wrote a blog post [https://www.morling.dev/blog/zipping-gatherer/] about his `zip` Gatherer saying "Java 22 [...] promises to improve the situation here." and none of his readers pointed out that his Gatherer is not compliant either (nor complained that his Gatherer is not reusable).

Kind regards, Anthony

September 19, 2024 at 11:30 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> Hi Anthony,
> 
> Bear with me for a moment,
> 
> in the same vein as there's nothing which *enforces*?equals(?) or hashCode() to be conformant to their specs, or any interface-implementation for that matter, I don't see how we could make any stronger enforcement of Gatherers.
> 
> >My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
> 
> Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather). Ultimately, it all boils down to specification?if an equals(?)-method implementation leads to surprising behavior when used with a collection, one typically needs to first ensure that the equals(?)-method conforms to its expected specification before one can presume that the collection has a bug.
> 
> For the "just work"?scenario, one can only make claims about things which have been proven. So in this case, what tests have passed for the implementation in question?
> 
> >Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction.?
> java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?
> 
> >?"protecting the users from being given non-reusable Gatherers"
> Think of it more like increasing the odds that users are given spec-conformant Gatherers.
> 
> Cheers,
> 
> ?
> 
> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle
> 
> ????????????????????????????????????????????????????????????????
> 
> **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:**?Wednesday, 18 September 2024 18:27
> **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> ?
> 
> Hi Viktor
> 
> Let me start with a question: is the requirement (a) "a Gatherer SHOULD be reusable", or (b) "a Gatherer MUST be reusable"?
> 
> As of today the specification says (b), whereas the implementation matches (a).
> 
> In case of (a), I propose to align the specification to allow for compliant, non-reusable Gatherers.
> 
> In case of (b), I propose to align the implementation to enforce compliance. Something like:
> 
> (1) invoke `initializer()` twice, giving `i1` and `i2`. Discard `i1` and invoke `i2` twice, giving `state1` and `state2`.
> 
> (2) invoke `finisher()` twice, giving `f1` and `f2`. Discard `f1` and invoke `f2` twice, the first time with `state1` and a dummy Downstream, the second time with the actual final state, i.e. `state2` after all elements were integrated, and the actual Downstream.
> 
> Then backport this change to JDK 23 & 22 and/or do another round of preview in JDK 24.
> 
> I'm confident that enforcing compliance would result in significant amounts of feedback questioning the requirement.
> 
> My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
> 
> Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction. You say:
> 
> > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
> 
> so I'd guess the rationale is?"protecting the users from being given non-reusable Gatherers".
> 
> However, I can't readily think of a situation where this would be essential.
> 
> If a user creates a Gatherer by invoking a factory method, the factory method can specify whether its result is reusable.
> 
> And if a user is given a Gatherer as a method argument, and they need the Gatherer to be reusable, they could change the parameter to a `Supplier<Gatherer>` instead.
> 
> > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
> 
> >
> 
> > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
> 
> We agree, just that I'd provide 2 factory methods, `concat(Stream<T>)` (non-reusable) and `append(List<T>)` (reusable), whereas you'd provide a 2-in-1 `concat(Supplier<Stream<T>>)`.
> 
> Kind regards, Anthony
> 
> September 12, 2024 at 11:55 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > Hi Anthony
> 
> >
> 
> > Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.
> 
> >
> 
> > >While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
> 
> >
> 
> > To me, this is governed by the following parts of the Gatherer specification https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html?:
> 
> >
> 
> > "Each invocation of initializer() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer()?,integrator()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator()?,combiner()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner()?, and finisher()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher()??must return a semantically identical result."
> 
> >
> 
> > and
> 
> >
> 
> > "Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstreamGatherer.Downstreamhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html?PREVIEWhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream??for longer than the invocation duration of the method which they are passed to."
> 
> >
> 
> > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
> 
> >
> 
> > For Stream, the assumption is that they are NOT reusable at all.
> 
> > For Gatherer, I think the only reasonable assumption is that they are reusable.
> 
> >
> 
> > >In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?
> 
> >
> 
> > Not necessarily, if the factory method **consumes**?the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.
> 
> >
> 
> > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
> 
> >
> 
> > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
> 
> >
> 
> > >As another example, take Gunnar Morling's zip Gatherers:?
> 
> >
> 
> > I don't see how Gatherers like this could be made reusable, or why that would even be desirable.
> 
> >
> 
> > Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().
> 
> >
> 
> > >My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
> 
> >
> 
> > My apologies, I misunderstood. To me, the operation you describe is called `inject`.
> 
> > Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.
> 
> >
> 
> > Thanks again for the great questions and conversation, it's valuable!
> 
> > Cheers,
> 
> >
> 
> > ?
> 
> >
> 
> > **Viktor Klang**
> 
> > Software Architect, Java Platform Group
> 
> >
> 
> > Oracle
> 
> >
>

From liach at openjdk.org  Thu Sep 19 19:03:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Sep 2024 19:03:36 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v5]
In-Reply-To: <JVD5pJEx0TJtcPBZ0NQ2_M7if91ifyRCR8J5F4zMIpw=.4b1be13e-65fa-4c79-be7b-7da3afd461a7@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <JVD5pJEx0TJtcPBZ0NQ2_M7if91ifyRCR8J5F4zMIpw=.4b1be13e-65fa-4c79-be7b-7da3afd461a7@github.com>
Message-ID: <Wce8V4DCQRF-I26gSfGtXfNVlqkYKdbvVqyO2E2H_UQ=.f3df2d25-a6a6-4800-9482-e88185853223@github.com>

On Mon, 16 Sep 2024 14:23:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/io/ObjectOutputStream.java line 2047:

> 2045:                     writeByte(TC_LONGSTRING);
> 2046:                 }
> 2047:                 writeLong(utflen);

The old plain `writeUTF` does not write a long utf if the length is too long, but rather throws an `UTFDataFormatException`. There should be code paths that no longer throw this exception, because a few tests, including:
- `java/io/Serializable/longString/LongString.java`
- `java/io/Serializable/sanityCheck/SanityCheck.java`
- `java/text/Format/DateFormat/DateFormatRegression.java`
are failing. I think this might be the root cause.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20886#pullrequestreview-2316520096
PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1767459534

From bpb at openjdk.org  Thu Sep 19 20:36:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Sep 2024 20:36:34 GMT
Subject: RFR: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
Message-ID: <ixGdxhPfnVpyvSpt-YQhWymGI6wcirpr5Nug2-m--sE=.a8fd43b0-25c4-4419-ad8e-e5ecb0282f0f@github.com>

On Sun, 8 Sep 2024 07:52:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20903#pullrequestreview-2316686796

From macarte at openjdk.org  Thu Sep 19 20:58:39 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 20:58:39 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
Message-ID: <CL-GkuP7IXVrQWPke9fOsKwby0WHgR5JqysChDSCn20=.7601f677-5ef3-4ed9-b805-1d650997d708@github.com>

On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

src/hotspot/share/cds/metaspaceShared.cpp line 673:

> 671:   }
> 672: 
> 673:   if (AOTMode != nullptr && strcmp(AOTMode, "create") == 0) {

Would it be better to wrap this test in a CDSConfig::is_ method; which in turn can test the AOTMode FLAG directly or test (CDSConfig::is_dumping_static_archive() && !CDSConfig::is_old_cds_flags_used()), the point being that the meaning of the test is captured in the method name, but the test itself can change over time as needed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1767582528

From macarte at openjdk.org  Thu Sep 19 21:12:39 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 21:12:39 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
Message-ID: <OI7ENirbce64xiExQ01VWaUtLaLbFGGuFSnxRVEUiWQ=.13eef949-e8af-4a8e-b3dc-e8112bae5061@github.com>

On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 40:

> 38:       strcmp(value, "create") != 0 &&
> 39:       strcmp(value, "auto") != 0 &&
> 40:       strcmp(value, "on")) {

This should be strcmp(value, "on") != 0 ??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1767599737

From duke at openjdk.org  Thu Sep 19 21:15:11 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 19 Sep 2024 21:15:11 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v12]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  fix is_intrinsic_supported to work properly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/aa163896..5da2754a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=10-11

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From mcimadamore at openjdk.org  Thu Sep 19 21:25:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 21:25:21 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/0d7d0f9b..effefb50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From mcimadamore at openjdk.org  Thu Sep 19 21:25:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 21:25:21 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v2]
In-Reply-To: <m_1GRtyM32t0wgl1FRtjgBLDsNe4KfUCLb8PU2RD2YA=.0bdfb745-2f7b-42ad-990d-858b6c659e09@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
 <m_1GRtyM32t0wgl1FRtjgBLDsNe4KfUCLb8PU2RD2YA=.0bdfb745-2f7b-42ad-990d-858b6c659e09@github.com>
Message-ID: <YhlWv9tHYwMDSwnOrL8qQipG_eszuLzVUJGOtpMdqAE=.d4e0930b-991a-4ae1-a47e-69438f27d203@github.com>

On Thu, 19 Sep 2024 17:21:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move restricted method page to `java.lang`
>>   Update restricted method page
>
> src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 43:
> 
>> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,
>> 42:     or from an <a href="../Linker.html#upcallStub(java.lang.invoke.MethodHandle,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Arena,java.lang.foreign.Linker.Option...)">upcall stub</a>
>> 43:     and there is no caller class on the stack, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>
> 
>> there is no caller class on the stack
> 
> I feel like this could be a little more elaborate. I'm not sure if it's clear enough which 'stack' this is talking about, and what it means for a class to be on the stack, considering a reader who doesn't know that the caller of a caller-sensitive method is determined through a stack walk.
> 
> Maybe this could be a vague blanket statement instead, like:
> 
> Suggestion:
> 
>     and a Java caller can not be determined, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>
> 
> 
> Unfortunately, there doesn't seem to be a central place we can link to that describes how a caller for a caller sensitive method is determined, and in which cases it can not be determined (because there is no caller), which we could link to from here. There's a short discussion of caller sensitive methods [here](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#callsens), but it doesn't explain how the caller is determined.

I agree this text is not great. I borrowed it largely from:

https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/reflect/AccessibleObject.html#canAccess(java.lang.Object)

But it's true that it refers to a lot of "magic" terminology that is not really explained anywhere. Unfortunately, explaining what a caller sensitive method is does not belong in here either (maybe at some point we should have another static page for that :-) ).

I agree that a vague statement looks better in here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1767608463

From macarte at openjdk.org  Thu Sep 19 21:25:37 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 21:25:37 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
Message-ID: <HvWeBYsJw0wH1fD1Sqkkq7tbChU-Wls6NFGGTCheYtM=.bb7a32f8-53f0-49bc-a0c0-f028299e38be@github.com>

On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java line 51:

> 49:     }
> 50: 
> 51:     static void positiveTests() throws Exception {

Missing a test for AOTMode=on, I think this would have identified the issue in the constraint test which currently fails if you specify AOTMode=on

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1767611760

From sviswanathan at openjdk.org  Thu Sep 19 21:43:01 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 19 Sep 2024 21:43:01 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v4]
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <Dn3kYpqZ1K-y5ToZT_8UXpTCVgvs_Grepf9OwmybEdY=.1ce7bf07-f85f-4f50-81bf-e3353ffac8b7@github.com>

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Implement review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20634/files
  - new: https://git.openjdk.org/jdk/pull/20634/files/87e103ee..f8e67fb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20634&range=02-03

  Stats: 27 lines in 1 file changed: 9 ins; 8 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20634.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20634/head:pull/20634

PR: https://git.openjdk.org/jdk/pull/20634

From sviswanathan at openjdk.org  Thu Sep 19 21:43:02 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 19 Sep 2024 21:43:02 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v3]
In-Reply-To: <2pPJKmEHM24iStw8Xv2IQ08Xrp7Ag3P2_9yEzsS4nOw=.49f3554d-0917-40ff-8824-d8719c3d271f@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <ejjSF36eH_T1oSpZTNgdcE-ayvxalBb6U0brArvq4K4=.642fa6e6-e424-4f9c-ad74-3b752241547c@github.com>
 <2pPJKmEHM24iStw8Xv2IQ08Xrp7Ag3P2_9yEzsS4nOw=.49f3554d-0917-40ff-8824-d8719c3d271f@github.com>
Message-ID: <j5sQbf_0OwLgCbLzRIpmwMJqO4SMqx1lmpu0IGbnNik=.13f3d906-62bb-488a-9cf7-f8b8a628c2c0@github.com>

On Thu, 19 Sep 2024 07:29:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change method name
>
> Hi @sviswa7 , some comments, overall patch looks good to me.
> 
> Best Regards,
> Jatin

Thanks a lot @jatin-bhateja. I have implemented your review comments.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 772:
> 
>> 770: 
>> 771:   if (elem_klass == nullptr || shuffle_klass == nullptr || shuffle->is_top() || vlen == nullptr) {
>> 772:     return false; // dead code
> 
> Why dead code  in comment ? this is a failed intrinsification condition.

Modified comment.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 776:
> 
>> 774:   if (!vlen->is_con() || shuffle_klass->const_oop() == nullptr) {
>> 775:     return false; // not enough info for intrinsification
>> 776:   }
> 
> Why don't you club it with above conditions to be consistent with other inline expanders ?

Done

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2120:
> 
>> 2118: 
>> 2119:   if (vector_klass == nullptr  || elem_klass == nullptr || vlen == nullptr) {
>> 2120:     return false; // dead code
> 
> Why dead code in comments ?

Modified comment.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2129:
> 
>> 2127:                     NodeClassNames[argument(2)->Opcode()],
>> 2128:                     NodeClassNames[argument(3)->Opcode()]);
>> 2129:     return false; // not enough info for intrinsification
> 
> Please club this with above condition to be consistent with other inline expanders.

done

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2144:
> 
>> 2142:   int num_elem = vlen->get_con();
>> 2143:   if ((num_elem < 4) || !is_power_of_2(num_elem)) {
>> 2144:     log_if_needed("  ** vlen < 4 or not power of two=%d", num_elem);
> 
> Will num_elem < 4  not be handled by L2149 since we have an implementation limitation to support less than 32-bit shuffle / masks.

Yes that should handle it.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2171:
> 
>> 2169:     use_predicate = false;
>> 2170:     if(!is_masked_op ||
>> 2171:        (!arch_supports_vector(Op_VectorRearrange, num_elem, elem_bt, VecMaskNotUsed) ||
> 
> Suggestion:
> 
>        (!arch_supports_vector(Op_VectorRearrange, num_elem, elem_bt, VecMaskUseLoad) ||

Here it should be VecMaskNotUsed as this case it using blend to emulate masking. The VecMaskUseLoad case is checked at line 2168.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2188:
> 
>> 2186: 
>> 2187:   if (v1 == nullptr || v2 == nullptr) {
>> 2188:     return false; // operand unboxing failed
> 
> To be consistent with other expanders please emit proper error for unboxing failure like on following line.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L426

done

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2197:
> 
>> 2195:     mask = unbox_vector(argument(6), mbox_type, elem_bt, num_elem);
>> 2196:     if (mask == nullptr) {
>> 2197:       log_if_needed("  ** not supported: op=selectFrom vlen=%d etype=%s is_masked_op=1",
> 
> Error should an unboxing failure here.

done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2362249672
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767601917
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767602096
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767605028
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767605213
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767607670
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767610833
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767615559
PR Review Comment: https://git.openjdk.org/jdk/pull/20634#discussion_r1767617255

From sviswanathan at openjdk.org  Thu Sep 19 21:45:36 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 19 Sep 2024 21:45:36 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v2]
In-Reply-To: <BaR7EYBiZ49GpDDiEuglTF4vqeyhO3oMnPJGf40_E74=.6121a64d-8e74-4a53-9d2d-f17c6dcf8043@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <Ea32gUuD_ZyvmFBGhWQwavOPUX4azRxAQVqiqiVVFxs=.2ae4eb2b-5cd8-4d26-95fb-da4d172b69d9@github.com>
 <BaR7EYBiZ49GpDDiEuglTF4vqeyhO3oMnPJGf40_E74=.6121a64d-8e74-4a53-9d2d-f17c6dcf8043@github.com>
Message-ID: <_Q0HCE6Lc7LZY8Sc5XzQvLHg_WdeCDOAGZgMOeEWK4M=.d28c8b11-ee52-4551-92b8-357c04a4d5ef@github.com>

On Wed, 18 Sep 2024 12:23:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> I'm a bit confused by the name `shuffleWrapIndexes` and `inline_vector_shuffle_wrap_indexes`.
> 
> Are you **shuffling wrap-indexes**? I don't know what that would even mean. I think you should name it `wrapShuffleIndexes`. Or is there any naming convention in the VectorAPI that prevents this?

Thanks a lot @eme64 for the review. I have implemented your review comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2362253398

From macarte at openjdk.org  Thu Sep 19 21:46:35 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 21:46:35 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
Message-ID: <tt1aTJvbJbIoaOpSzJlZjixS5PwCVh4dCHwlhlc-Yo8=.fa20b168-3575-4dfe-a31f-8332b5799f8d@github.com>

On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

src/hotspot/share/cds/cds_globals.hpp line 102:

> 100:   /* See CDSConfig::check_flag_aliases().                               */  \
> 101:                                                                             \
> 102:   product(ccstr, AOTMode, nullptr,                                          \

you can replace nullptr with "auto" as that's the default, that would simplify some of the FLAG_IS_DEFAULT(AOTMode) || (strcmp(AOTMode, "auto") == 0 checks.  So you would now check strcmp(AOTMode, "auto") == 0 which I guess is slightly less performant (as FLAG_IS_DEFAULT is a cheap early out), however the current implementation means that the definition of the default value can spread across the codebase vs only being specified in cds_globals.h

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1767636303

From macarte at openjdk.org  Thu Sep 19 22:08:35 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 22:08:35 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <OI7ENirbce64xiExQ01VWaUtLaLbFGGuFSnxRVEUiWQ=.13eef949-e8af-4a8e-b3dc-e8112bae5061@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
 <OI7ENirbce64xiExQ01VWaUtLaLbFGGuFSnxRVEUiWQ=.13eef949-e8af-4a8e-b3dc-e8112bae5061@github.com>
Message-ID: <ldTVx6sJ5Ftd_GU1UVehsbpXIdtORVyr1kbgP_0kKEU=.1e679d6d-f69d-46c2-964c-df94869e3bfd@github.com>

On Thu, 19 Sep 2024 21:09:43 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
>
> src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 40:
> 
>> 38:       strcmp(value, "create") != 0 &&
>> 39:       strcmp(value, "auto") != 0 &&
>> 40:       strcmp(value, "on")) {
> 
> This should be strcmp(value, "on") != 0 ??

Okay both ways are valid, you could also remove the other "!= 0", the mixing was confusing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1767653154

From jjg at openjdk.org  Thu Sep 19 22:15:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 19 Sep 2024 22:15:38 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
Message-ID: <tr3sE4c2DTU7iMbdn6cC6Z6TbCvaPwE9_MBIHPaYhWc=.5c95ef32-7c71-441a-85a6-a369911475a7@github.com>

On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Skip over files and packages that aren't found
>  - Move the tests to module/module_name directory for clearer naming
>  - (C)
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e

test/jdk/tools/sincechecker/SinceChecker.java line 152:

> 150:             String version = String.valueOf(i);
> 151:             Elements elements = ct.getElements();
> 152:             elements.getModuleElement("java.base"); // forces module graph to be instantiated

@lahodaj I've always considered this kind of line to be a workaround; it would be nice if we could have an RFE so this kind of line was unnecessary

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1767657515

From jjg at openjdk.org  Thu Sep 19 22:24:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 19 Sep 2024 22:24:39 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
Message-ID: <Blo_bdOTHPXENX9FECq3Ig2rQQizYB0ooE464SerT_o=.82e709f2-2048-4c34-9325-fd2d0c1acd8c@github.com>

On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Skip over files and packages that aren't found
>  - Move the tests to module/module_name directory for clearer naming
>  - (C)
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e

test/jdk/tools/sincechecker/SinceChecker.java line 50:

> 48: import jtreg.SkippedException;
> 49: 
> 50: /*

Good comment.

test/jdk/tools/sincechecker/SinceChecker.java line 828:

> 826:             }
> 827:             if (version == null) {
> 828:                 //may be null for private elements

empty statement for `if`...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1767663271
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1767662297

From jlu at openjdk.org  Thu Sep 19 22:29:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 22:29:58 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security tests
Message-ID: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>

Please review this PR which removes usages of Applet within the corelibs tests. This includes both code usage as well as occurrences of the word.

There were more files found than the ones included in this PR, please see the comment on the JBS issue for the reason why they were not included. In general, I removed the file if the entirety was focused on Applet, otherwise I removed the portions applicable.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21096/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340326
  Stats: 433 lines in 11 files changed: 2 ins; 411 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21096/head:pull/21096

PR: https://git.openjdk.org/jdk/pull/21096

From jjg at openjdk.org  Thu Sep 19 22:37:41 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 19 Sep 2024 22:37:41 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
Message-ID: <iYvFt_iZgORda9yMGzfJao-4dIZAMpkLsra_b9jmSN4=.156de574-0972-48a3-b8e9-42f412275c6f@github.com>

On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Skip over files and packages that aren't found
>  - Move the tests to module/module_name directory for clearer naming
>  - (C)
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e

Generally very good. It's getting to be a really nice piece of functionality.

I added one suggestion for a minor improvement, about setting up the `EXCLUDE_LIST in a more module-specific way.  The intent is that if we need to make module-specific changes to the exclude list in times going forward, we should do that in the module-specific test invocation, and not in the main module-independent code.

test/jdk/tools/sincechecker/SinceChecker.java line 114:

> 112:     private static final Set<String> EXCLUDE_LIST = Set.of(
> 113:             "java.lang.classfile"
> 114:     );

This should not really be here, in the general code for a SinceChecker for all modules.

It would be better if this info was provided in command-line options, given when the test is run from the module-specific test (i.e. `CheckSince_javaBase.java`). 

This means you will have to write some additional simple option decoding in the `main` method, starting line 21.

test/jdk/tools/sincechecker/modules/java_base/CheckSince_javaBase.java line 33:

> 31:  *          jdk.compiler/com.sun.tools.javac.util
> 32:  *          jdk.compiler/com.sun.tools.javac.code
> 33:  * @run main SinceChecker java.base

See the comment about init-ing the EXCLUDE_LIST in the main SinceChecker, at about line 112.

You are already paying a module name as an option to the main test. Maybe the command here on line 33 could be something like

@run main SinceChecker java.base --exclude java.lang.classfile

where the argument after `--exclude` is (logically) a comma-separated list of items to exclude. You could also do a whitespace-separated list up to the next option (i.e. item beginning with `-`) or end of the list. In other words make it future-proof against adding more options in future.

-------------

Changes requested by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2316850250
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1767666131
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1767669975

From jjg at openjdk.org  Thu Sep 19 22:52:49 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 19 Sep 2024 22:52:49 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
Message-ID: <shC95WXDgvdLzxVh-g-KI61ZALEzEuYgpGJWoXaQQ1c=.6a4674ca-a9db-4a67-82df-3ab64130e1d6@github.com>

On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Skip over files and packages that aren't found
>  - Move the tests to module/module_name directory for clearer naming
>  - (C)
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e

For discussion:

I see that in GitHub Actions, the test passes on all platforms. (That's good!). But it's not clear to me that it _needs_ to run on all platforms. Generally, the API should be the same on all platforms, right (After all, we only generate one set of API documentation.) 

So, the question becomes, can a test determine if it is being run in a multi-platform context?  We presumably don't want to stop the test running whenever a user runs it locally on their platform of choice, but equally, if the test is being run on many platforms, that's an unnecessary use/waste of resources.  But, I guess we run a lot of tests that are essentially platform-independent on all platforms, although I guess there're are also testing the product running on top of the JVM, whereas here. we're primarily just checking the source.

Anyway, this is really just an abstract academic discussion, not a blocker in any way for the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2362333169

From asemenyuk at openjdk.org  Thu Sep 19 23:43:50 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 19 Sep 2024 23:43:50 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle
Message-ID: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>

Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.

-------------

Commit messages:
 - 8338918: Remove non translated file name from WinResources resource bundle

Changes: https://git.openjdk.org/jdk/pull/21100/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338918
  Stats: 80 lines in 9 files changed: 41 ins; 13 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/21100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21100/head:pull/21100

PR: https://git.openjdk.org/jdk/pull/21100

From psandoz at openjdk.org  Thu Sep 19 23:52:35 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Sep 2024 23:52:35 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <yRWggFZtBOqgWv1GxOvmkdVZvr7BfeGr5rTeOTxMTBs=.af30d6eb-6ff1-49db-9a47-d68a2972f6b6@github.com>

On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

> Got it, I think #20508 and this PR are unrelated implementation-wise, though.

It would be nice if we can move independently of #20508 as that may take longer to integrate because of API/CSR review.

> 
> @jatin-bhateja What do you think of using this patch and intrinsifing `Vector<E>::rearrange(VectorShuffle<E>, Vector<E>)` instead of introducing the 2 vector `selectFrom` API?

IMO the two-vector `selectFrom` API is complementary to the existing single-vector `selectFrom`, and both have equivalent `rearrange` expressions. For either use we should ideally get to the point that a similar/identical optimal instruction sequence is generated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2362388082

From sviswanathan at openjdk.org  Fri Sep 20 00:12:48 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 20 Sep 2024 00:12:48 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v12]
In-Reply-To: <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
Message-ID: <td9DkaPYfvs4N_-YPewTkqod0K76Q7ton3dBQ8_8qWw=.2d8e747a-0007-42ab-94f2-e643727f4514@github.com>

On Thu, 19 Sep 2024 21:15:11 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix is_intrinsic_supported to work properly

The PR looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20657#pullrequestreview-2316948493

From weijun at openjdk.org  Fri Sep 20 00:40:01 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 20 Sep 2024 00:40:01 GMT
Subject: RFR: 8340493: Fix some Asserts failure messages
Message-ID: <_nQ0hPZLDkS0LOIg4Z4itXpyGCSasSSuid4Gz3fm3Kc=.6d0ba0ad-0aa3-4ccf-80a1-e13017fd33fa@github.com>

`Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which sounds redundant, just say "expected not equals but was 12345".

`Asserts.assertEqualsByteArray` uses the words "expected... to equal...". Modify it to follow the `assertEquals` style ""expected... but was...".

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/21101/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340493
  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21101/head:pull/21101

PR: https://git.openjdk.org/jdk/pull/21101

From almatvee at openjdk.org  Fri Sep 20 01:08:41 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 20 Sep 2024 01:08:41 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle
In-Reply-To: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
Message-ID: <skaqsPEpqU8DEkyjAlKWX07D17WChJK7Bbtk1TIVUK0=.9ee7e2ab-01ff-4e25-ab5e-1a1f78ff3012@github.com>

On Thu, 19 Sep 2024 23:37:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 33:

> 31: param.menu-group.default=Unbekannt
> 32: 
> 33: resource.executable-properties-template=Vorlage f?r das Erstellen der ausf?hrbaren Eigenschaftendatei

Looks good. Do you know why this file show changes? Maybe you saved with wrong encoding or line ending?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21100#discussion_r1767790084

From dholmes at openjdk.org  Fri Sep 20 01:19:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Sep 2024 01:19:40 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <ldTVx6sJ5Ftd_GU1UVehsbpXIdtORVyr1kbgP_0kKEU=.1e679d6d-f69d-46c2-964c-df94869e3bfd@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
 <OI7ENirbce64xiExQ01VWaUtLaLbFGGuFSnxRVEUiWQ=.13eef949-e8af-4a8e-b3dc-e8112bae5061@github.com>
 <ldTVx6sJ5Ftd_GU1UVehsbpXIdtORVyr1kbgP_0kKEU=.1e679d6d-f69d-46c2-964c-df94869e3bfd@github.com>
Message-ID: <-GBifUfOpYOIAGRlwLOr_gYXgXsBsotpnyOAvSzVSKE=.49b786f2-f3e4-4f64-a933-e26ea12608f9@github.com>

On Thu, 19 Sep 2024 22:06:14 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 40:
>> 
>>> 38:       strcmp(value, "create") != 0 &&
>>> 39:       strcmp(value, "auto") != 0 &&
>>> 40:       strcmp(value, "on")) {
>> 
>> This should be strcmp(value, "on") != 0 ??
>
> Okay both ways are valid, you could also remove the other "!= 0", the mixing was confusing

Hotspot style rule is "no implicit booleans" so the check for `!= 0` should be used in all cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1767795254

From dholmes at openjdk.org  Fri Sep 20 02:36:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Sep 2024 02:36:39 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <3Nt65-I0eETs2YZZ3Pr3Tq6NmPSYCnmXdNONuuht9Xw=.2dbb43c3-a26d-445b-a50d-b2e798d22454@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <XH6kvzP6J5_bzVziFnygM0mV8gc4M9WP9yc4VOT5H1E=.6c72b5fc-2bcb-44f4-b6b5-05a24a7c933d@github.com>
 <3Nt65-I0eETs2YZZ3Pr3Tq6NmPSYCnmXdNONuuht9Xw=.2dbb43c3-a26d-445b-a50d-b2e798d22454@github.com>
Message-ID: <PGAaOL1zMIFgt2TMIlYW_Jhut2JAnXCL40jisMFo918=.328dcb84-ab6f-4019-bcf0-58dbd972ddc0@github.com>

On Thu, 19 Sep 2024 12:29:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> And I claim that this is outside the scope of this PR.

And I strongly disagree because the only reason I conceded that this documentation issue need not be addressed by the CSR request for JEP 472 was because JDK-8338596 was filed to address it - ref the comment from @jddarcy :
https://bugs.openjdk.org/browse/JDK-8331672?focusedId=14699206&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699206

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2362589095

From asemenyuk at openjdk.org  Fri Sep 20 02:45:39 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Sep 2024 02:45:39 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle
In-Reply-To: <skaqsPEpqU8DEkyjAlKWX07D17WChJK7Bbtk1TIVUK0=.9ee7e2ab-01ff-4e25-ab5e-1a1f78ff3012@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <skaqsPEpqU8DEkyjAlKWX07D17WChJK7Bbtk1TIVUK0=.9ee7e2ab-01ff-4e25-ab5e-1a1f78ff3012@github.com>
Message-ID: <so7TKrhtUQOdCfVvAu8mJJp5zlLRdz-oPRnKNhzA6pM=.d79bd327-c989-4462-921d-7fb9a8b2f34d@github.com>

On Fri, 20 Sep 2024 01:06:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 33:
> 
>> 31: param.menu-group.default=Unbekannt
>> 32: 
>> 33: resource.executable-properties-template=Vorlage f?r das Erstellen der ausf?hrbaren Eigenschaftendatei
> 
> Looks good. Do you know why this file show changes? Maybe you saved with wrong encoding or line ending?

Ugh, the diff looked right in TortoiseGit. I'll fix it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21100#discussion_r1767844835

From asemenyuk at openjdk.org  Fri Sep 20 02:53:00 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Sep 2024 02:53:00 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
Message-ID: <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>

> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Redo removal of `resource.wxl-file-name` property
 - Revert "8338918: Remove non translated file name from WinResources resource bundle"
   
   This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21100/files
  - new: https://git.openjdk.org/jdk/pull/21100/files/9b3c1a59..9562086c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21100&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21100&range=00-01

  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21100/head:pull/21100

PR: https://git.openjdk.org/jdk/pull/21100

From amitkumar at openjdk.org  Fri Sep 20 04:09:40 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 20 Sep 2024 04:09:40 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v6]
In-Reply-To: <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>
Message-ID: <6mePQ-uHpmaHQrkZ8IqPNmH9Zbpd9ACeruRj1edeDi8=.d93dfea7-d746-46c6-b9f4-4826f775cf28@github.com>

On Thu, 19 Sep 2024 12:20:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - use resolve_global_jobject on s390
>  - Merge branch 'master' into LoadVMTraget
>  - remove PC save/restore on s390
>  - use fatal()
>  - add RISC-V as target platform
>  - Adjust ppc & RISC-V code
>  - Add s390 changes
>  - Merge branch 'master' into LoadVMTraget
>  - Don't save/restore LR/CR + resolve_jobject on s390
>  - eyeball other platforms
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/2faf8b8d...b703b162

I ran tier1-tests on release & fastdebug VMs for s390x. Didn't see any new failure appearing. s390x part seems good to me.

Marked as reviewed by amitkumar (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20479#pullrequestreview-2317183506
PR Review: https://git.openjdk.org/jdk/pull/20479#pullrequestreview-2317183803

From iklam at openjdk.org  Fri Sep 20 04:26:08 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 20 Sep 2024 04:26:08 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v4]
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <tXUTWVeOM0Q6TGoB5lXRCarPzWfzG1RtEBrtSRCj5GE=.04953f50-2cf8-44b7-9755-9315038cb757@github.com>

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 jep-483-step-01-8338017-add-aot-command-line-aliases
 - @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
 - Fixed copyright dates
 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Fixed whitespaces
 - 8338017: Add AOT command-line flag aliases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20516/files
  - new: https://git.openjdk.org/jdk/pull/20516/files/1da2ed9f..64ff73fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=02-03

  Stats: 174298 lines in 1393 files changed: 158710 ins; 8126 del; 7462 mod
  Patch: https://git.openjdk.org/jdk/pull/20516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20516/head:pull/20516

PR: https://git.openjdk.org/jdk/pull/20516

From swen at openjdk.org  Fri Sep 20 05:09:19 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Sep 2024 05:09:19 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v6]
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <r9skwi26EuGlQR8LniR4cwBL4DCkcNQHwjZSPiq0EAs=.5d8123bf-9fe0-46da-862d-31343134a661@github.com>

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix for write long utf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20886/files
  - new: https://git.openjdk.org/jdk/pull/20886/files/83fc4685..8d004285

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20886&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20886/head:pull/20886

PR: https://git.openjdk.org/jdk/pull/20886

From swen at openjdk.org  Fri Sep 20 05:12:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Sep 2024 05:12:37 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v5]
In-Reply-To: <Wce8V4DCQRF-I26gSfGtXfNVlqkYKdbvVqyO2E2H_UQ=.f3df2d25-a6a6-4800-9482-e88185853223@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <JVD5pJEx0TJtcPBZ0NQ2_M7if91ifyRCR8J5F4zMIpw=.4b1be13e-65fa-4c79-be7b-7da3afd461a7@github.com>
 <Wce8V4DCQRF-I26gSfGtXfNVlqkYKdbvVqyO2E2H_UQ=.f3df2d25-a6a6-4800-9482-e88185853223@github.com>
Message-ID: <60K2vsPghqaIjHhURfxfAUQdY_vl6CLjW4Xlru53XEY=.151c62e3-bf60-4830-98fe-b5b922841781@github.com>

On Thu, 19 Sep 2024 19:00: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:
>> 
>>   suggestion from @liach
>
> src/java.base/share/classes/java/io/ObjectOutputStream.java line 2047:
> 
>> 2045:                     writeByte(TC_LONGSTRING);
>> 2046:                 }
>> 2047:                 writeLong(utflen);
> 
> The old plain `writeUTF` does not write a long utf if the length is too long, but rather throws an `UTFDataFormatException`. There should be code paths that no longer throw this exception, because a few tests, including:
> - `java/io/Serializable/longString/LongString.java`
> - `java/io/Serializable/sanityCheck/SanityCheck.java`
> - `java/text/Format/DateFormat/DateFormatRegression.java`
> are failing. I think this might be the root cause.

The reason for the error is that when the `drain` method is called, the local variable pos is not updated to the field `pos`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20886#discussion_r1767990262

From miiiinju00 at gmail.com  Fri Sep 20 06:58:20 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Fri, 20 Sep 2024 15:58:20 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
 <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>
Message-ID: <54269739-3040-4676-8D36-0363357CB151@gmail.com>

Hi Viktor, Archie, and Daniel,

I hope everything is going well on your end. I really appreciate the thoughtful feedback you've provided so far, and I wanted to follow up on our previous discussion about the potential fairness issue in ArrayBlockingQueue when using ReentrantLock with Condition.await().

In our previous conversation, I raised a concern regarding the separate waiting spaces for ReentrantLock's AQS and Condition.await() in ArrayBlockingQueue. Specifically, my understanding is that when a thread is signaled from Condition.await(), it is re-enqueued at the end of the AQS queue, which could potentially allow newly arriving threads to acquire the lock before threads that have been waiting on Condition.await() for longer. This separation of the AQS queue and the condition waiting space seems to introduce the possibility of FIFO violations and starvation, even in fair mode.

If the potential starvation caused by this behavior is something that needs to be addressed, I?ve been considering a solution that could help. One approach could be tracking the number of threads waiting when the queue is full. Here?s an example of how this might be implemented:

private volatile long putWaitingCount = 0L;

public void put(E e) throws InterruptedException {
    Objects.requireNonNull(e);
    final ReentrantLock lock = this.lock;

    // waitedBefore: A flag indicating whether the current thread has entered the await state in this iteration.
    boolean waitedBefore = false;
    lock.lockInterruptibly();
    try {
        /**
         * If there are waiting threads, the current thread joins the wait queue.
         * Threads entering this condition are implicitly guaranteed that count == capacity.
         * Therefore, it's safe to use await() without wrapping it in a loop here.
         */
        if (putWaitingCount > 0) {
            ++putWaitingCount;
            waitedBefore = true;
            notFull.await();
        }
        while (count == items.length) {
            if(!waitedBefore) {
                ++putWaitingCount;
                waitedBefore = true;
            }
            notFull.await();
        }
        enqueue(e);
    } finally {
        // If the thread had waited, decrement the waiting thread count.
        if (waitedBefore) {
            --putWaitingCount;
        }
        lock.unlock();
    }
}

In this approach, the number of threads currently waiting on Condition.await() is tracked by a simple counter, putWaitingCount. This ensures that newly arriving threads do not bypass those that have already been waiting when the queue is full.

I?d love to hear your thoughts on whether the starvation issue caused by the separation of AQS and Condition.await()waiting spaces is something worth addressing, and if so, whether the approaches I?ve suggested could be effective in resolving it. If this direction seems promising, I?d be happy to continue refining the solution based on your feedback.

Thanks again for your time and consideration. I truly appreciate the opportunity to engage with you and learn through this process.

Best regards,

Minju Kim


> 2024. 9. 11. ?? 1:33, ??? <miiiinju00 at gmail.com> ??:
> 
> Hi Archie and Viktor,
> 
> I apologize for the delay in my response.
> 
> 
> 
> After further consideration, I believe my understanding aligns more closely with Interpretation B.
> 
> To clarify my understanding of Interpretation B, threads waiting on a Condition (linked through ConditionNode in ConditionObject) receive signals in the order in which they started waiting, but receiving a signal doesn't guarantee immediate reacquisition of the ReentrantLock. Instead, as far as I understand, the signal simply enqueues the thread at the end of the AQS queue(ReentrantLock).
> 
> 
> 
> As a result, threads that received a signal from ConditionObject do not have priority over the threads already waiting in the AQS queue and are simply added to the end of that queue.
> 
> From what I understand, the difference between NonFairSync and FairSync lies in whether a thread can acquire the lock when there are other threads already waiting in the AQS queue, rather than anything related to the threads signaled from a Condition.
> 
> 
> 
> Additionally, as I understand it, the enqueue() and doSignal() methods are declared final in AQS, and both Syncimplementations use the AQS methods directly.
> 
> 
> 
> Therefore, I wanted to highlight that this isn't necessarily an issue with AQS or FairSync. Instead, I suspect that the behavior we're seeing could arise from the fact that threads signaled in a BlockingQueue implementation may not execute immediately, which is a characteristic of the implementation.
> 
> 
> 
> However, there may be aspects I?m misunderstanding, and I would appreciate any corrections or clarifications if that?s the case.
> 
> 
> 
> Thank you very much for your time and understanding.
> 
> Best regards,
> 
> Kim Minju
> 
> 
>> 2024. 9. 8. ?? 11:39, Archie Cobbs <archie.cobbs at gmail.com> ??:
>> 
>> Hi Kim,
>> 
>> Thanks for the details.
>> 
>> So to summarize:
>> Kim is saying that "Interpretation B" is how it actually works.
>> Viktor is saying that "Interpretation A" is how it actually works.
>> Do I have that right?
>> 
>> -Archie
>> 
>> P.S. Viktor: my apologies for misspelling your name before
>> 
>> 
>> On Sat, Sep 7, 2024 at 8:04?PM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>>> Hi Arhice,
>>> 
>>> 
>>> 
>>> First of all, I want to apologize if I may not have explained things clearly since English is not my first language. I?m really sorry about that.
>>> 
>>> 
>>> 
>>> Even so, I deeply appreciate your response and taking the time to reply.
>>> 
>>> 
>>> 
>>> First, I would like to confirm whether my understanding is correct.
>>> 
>>> From what I know, ReentrantLock is based on AQS, and internally, threads are queued by being linked as Node.
>>> 
>>> When ReentrantLock.newCondition is called, a ConditionObject is created. When Condition::await is called, the thread waits based on a ConditionNode, and the AQS head is replaced with AQS::signalNext, allowing the lock to be released. At this point, I understand that the node disappears from the AQS queue and starts waiting within the ConditionNode of the ConditionObject.
>>> 
>>> As a result, I understand that the waiting places for ReentrantLock and Condition are different.
>>> 
>>> To summarize, when Condition::await() is called, the node that was previously waiting in AQS receives the lock, disappears from the AQS queue, and starts waiting within the ConditionNode of the ConditionObject.
>>> 
>>> Additionally, from what I understand, in Condition::doSignal, the first ConditionNode is removed, and then AQS::enqueue adds it to the tail of AQS.
>>> 
>>> public class ConditionObject implements Condition, java.io.Serializable {
>>> 
>>> private void doSignal(ConditionNode first, boolean all) {
>>>     while (first != null) {
>>>         ConditionNode next = first.nextWaiter;
>>>         if ((firstWaiter = next) == null)
>>>             lastWaiter = null;
>>>         if ((first.getAndUnsetStatus(COND) & COND) != 0) {
>>>             enqueue(first);
>>>             if (!all)
>>>                 break;
>>>         }
>>>         first = next;
>>>     }
>>> }
>>> 
>>> When enqueue is called:
>>> 
>>> public abstract class AbstractQueuedSynchronizer
>>>     extends AbstractOwnableSynchronizer
>>> 
>>>     /*
>>>      * Tail of the wait queue. After initialization, modified only via casTail.
>>>      */
>>>     private transient volatile Node tail;
>>> 
>>> 	 final void enqueue(Node node) {
>>> 	    if (node != null) {
>>> 	        for (;;) {
>>> 	            Node t = tail;
>>> 	            node.setPrevRelaxed(t);        // avoid unnecessary fence
>>> 	            if (t == null)                 // initialize
>>> 	                tryInitializeHead();
>>> 	            else if (casTail(t, node)) {
>>> 	                t.next = node;
>>> 	                if (t.status < 0)          // wake up to clean link
>>> 	                    LockSupport.unpark(node.waiter);
>>> 	                break;
>>> 	            }
>>> 	        }
>>> 	    }
>>> }
>>> 
>>> From my understanding, this attaches the node to the tail of AQS.
>>> 
>>> To elaborate further on the situation:
>>> 
>>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>>> 
>>> (At this point, T1 to T10 are linked through ConditionNode.) [The AQS queue is empty, while ConditionNode holds T1 to T10.]
>>> 
>>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>>> 
>>> (Since no threads are waiting in the AQS queue, T11 will acquire the lock immediately.)
>>> 
>>> [Now, AQS holds T11 at its head, and ConditionNode holds T1 to T10.]
>>> 
>>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (Since T11 is holding the lock with take(), T12 will be queued behind it in AQS.)
>>> 
>>> [Now, AQS holds T11 and T12, while ConditionNode holds T1 to T10.]
>>> 
>>> T11 reduces the count and sends a signal, then releases the lock.
>>> 
>>> T1 receives the signal and moves to the lock queue. Since ReentrantLock is in fair mode,
>>> 
>>> (When T11 sends the signal, T1, the first thread linked in ConditionNode, will be enqueued via AQS::enqueue. Now, AQS holds T11, T12, and T1, while ConditionNode holds T2 to T10.)
>>> 
>>> T11 releases the lock and wakes up T12.
>>> 
>>> [Now, AQS holds T12 and T1, while ConditionNode holds T2 to T10.]
>>> 
>>> T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without being blocked by while(count==length).
>>> 
>>> T12 releases the lock, and the next node in AQS is unparked.
>>> 
>>> [Now, AQS holds T1, while ConditionNode holds T2 to T10.]
>>> 
>>> T1, having reacquired the lock after Condition::await(), fails to exit the while loop and waits again.
>>> 
>>> [Now, ConditionNode holds T1 and T2 to T10.]
>>> 
>>> 
>>> 
>>> This is how I currently understand the situation.
>>> 
>>> If there are any mistakes in my understanding, I would greatly appreciate your clarification.
>>> 
>>> Best Regards,
>>> 
>>>  Kim Minju
>>> 
>>> 
>>>> 2024. 9. 8. ?? 3:34, Archie Cobbs <archie.cobbs at gmail.com <mailto:archie.cobbs at gmail.com>> ??:
>>>> 
>>>> Hi Kim,
>>>> 
>>>> On Sat, Sep 7, 2024 at 10:36?AM ??? <miiiinju00 at gmail.com <mailto:miiiinju00 at gmail.com>> wrote:
>>>>> Here's a clearer outline of the scenario:
>>>>> 
>>>>> Threads T1 to T10 are waiting on Condition::await() because the queue is full.
>>>>> T11 calls take() and holds the lock via lock.lockInterruptibly().
>>>>> T12 calls queue.put() and enters the wait queue for lock.lockInterruptibly(). (As I understand, the wait queue for ReentrantLock and Condition are separate.)
>>>>> T11 reduces the count and sends a signal, then releases the lock.
>>>>> T1 receives the signal and moves to the lock queue. Since the ReentrantLock is in fair mode, T12 (which was already waiting) gets priority, and T1 will acquire the lock later.
>>>>> T12 acquires the lock and successfully enqueues.
>>>> From one reading of the Javadoc, your step #5 ("T12 gets priority") is not supposed to happen that way. Instead, one of T1 through T10 should be guaranteed to acquire the lock.
>>>> 
>>>> Here it is again (from ReentrantLock.newCondition()):
>>>> 
>>>>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.
>>>> 
>>>> 
>>>> But part of the problem here is that this documentation is ambiguous.
>>>> 
>>>> The ambiguity is: are ALL threads trying to acquire the lock, whether on an initial attempt or after a condition wakeup, ordered for fairness together in one big pool? ? In this case step #5 can't happen. Call this Interpretation A.
>>>> 
>>>> Or is this merely saying that threads waiting on a condition reacquire the lock based on when they started waiting on the condition, but there are no ordering guarantees between those threads and any other unrelated threads trying to acquire the lock? ? In this case step #5 can happen. Call this Interpretation B.
>>>> 
>>>> So I think we first need to clarify which interpretation is correct here, A or B.
>>>> 
>>>> On that point, Victor said this:
>>>> 
>>>>> I've re-read ReentrantLock and AQS, and from my understanding on the logic the Condition's place in the wait queue should be maintained, which means that T3 shouldn't be able to "barge".
>>>> 
>>>> 
>>>> So it sounds like Victor is confirming interpretation A. Victor do you agree?
>>>> 
>>>> If so, then it seems like we need to do two things:
>>>> 
>>>> 1. File a Jira ticket to clarify the Javadoc, e.g. to say something like this:
>>>> 
>>>>> The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest. In the latter case, the ordering consideration includes all threads attempting to acquire the lock, regardless of whether or not they were previously blocked on the condition.
>>>> 
>>>> 
>>>> 2. Understand why Kim's updated test case is still failing (it must be either a bug in the test or a bug in ArrayBlockingQueue).
>>>> 
>>>> -Archie
>>>> 
>>>> --
>>>> Archie L. Cobbs
>>> 
>> 
>> 
>> --
>> Archie L. Cobbs
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240920/0262d55f/attachment-0001.htm>

From pminborg at openjdk.org  Fri Sep 20 07:28:40 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 07:28:40 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v5]
In-Reply-To: <o--l6IC9JxuNJ9SvI7YURxiImmj-vqRd0pWC2nWWBRc=.6f3881df-6e7e-4446-9255-e6fe1a5b6b57@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <o--l6IC9JxuNJ9SvI7YURxiImmj-vqRd0pWC2nWWBRc=.6f3881df-6e7e-4446-9255-e6fe1a5b6b57@github.com>
Message-ID: <qvfATZGAgXd4MoiELFmkP9icMRWjYiRpUOiqPbB3RhQ=.ae059d0a-dd94-4295-91ef-c9b180f71552@github.com>

On Tue, 17 Sep 2024 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> 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 nine additional commits since the last revision:
> 
>  - Merge branch 'master' into internal-mh-util
>  - Rename class and shorten JavaDoc
>  - Update javadoc
>  - Rename utility class
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

I've experimented a bit with using the `ConstantBoostraps::fieldVarHandle` method and here is what it looks like at a call site (example from `CompletableFuture`):


RESULT = ConstantBootstraps.fieldVarHandle(l, "result", VarHandle.class, CompletableFuture.class, Object.class);


Compared to:


RESULT = MhUtil.findVarHandle(l,  "result", Object.class);


One advantage is that we can remove two methods from the `MhUtil` class but the drawback is we need to add a lot of more parameters at the call sites. Eventually, both methods will work the same except from the exception handling. So, I think it is better to use the proposed `MhUtil` rather than `ConstantBootstraps`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2363013810

From pminborg at openjdk.org  Fri Sep 20 07:36:18 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 07:36:18 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v6]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <zN1MFo09uYUSr_-AdSvFEIh2_QqQTHdZWW6U7wsIBhM=.ccbbc5fa-6dd5-48b4-8123-2e8957b86304@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

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:

 - Simplify calls
 - Merge branch 'master' into internal-mh-util
 - Merge branch 'master' into internal-mh-util
 - Rename class and shorten JavaDoc
 - Update javadoc
 - Rename utility class
 - Move to new package and add overload
 - Merge branch 'master' into internal-mh-util
 - Rename and reformat
 - Fix copyright headers
 - ... and 1 more: https://git.openjdk.org/jdk/compare/85e28c70...5d9f1be9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/a1444c28..5d9f1be9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=04-05

  Stats: 20508 lines in 294 files changed: 18484 ins; 277 del; 1747 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From pminborg at openjdk.org  Fri Sep 20 08:14:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 08:14:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v7]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <RA9VMXnwmsFAOcCscNjIs2dmx3hYPQAbbJ0HfUje5SY=.e2de3ec3-41cc-4627-a3b3-265f9c96be1c@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried 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/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/5d9f1be9..67f90de7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

PR: https://git.openjdk.org/jdk/pull/20972

From pminborg at openjdk.org  Fri Sep 20 08:29:45 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 08:29:45 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddindLayout
Message-ID: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>

This PR prevents sequence layout with padding to be used with the Linker.

-------------

Commit messages:
 - Merge branch 'master' into linker-padding-layout-only
 - Improve excception message
 - Document a sequence layout cannot contain a padding layout
 - Update copyright year
 - Prevent embeded only padding layout in linker

Changes: https://git.openjdk.org/jdk/pull/21041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340205
  Stats: 30 lines in 3 files changed: 26 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From mcimadamore at openjdk.org  Fri Sep 20 08:44:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Sep 2024 08:44:35 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddindLayout
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <xCK_7Wp_fHgT4ZJ3-vs8qQ3V1vxGQdxfCudLbWWQvWA=.8b1a969c-b70b-4438-bac7-14dd3a2b1005@github.com>

On Tue, 17 Sep 2024 14:12:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR prevents sequence layout with padding to be used with the Linker.

The javadoc of the `Linker` also states that:

> [A group layout] G does not contain padding other than what is strictly required to align
     its non-padding layout elements, or to satisfy (2) [the size of {@code G} is a multiple of its alignment constraint]

I believe it is the intent here to rule out empty groups, or groups that contain only padding. Should we address that here (as I believe that once we add more checks, we'll need more tweaks to make the various exception more uniform) ?

Btw, if my interpretation of the javadoc is correct, I believe we should strengthen the javadoc a bit, by saying explicitly that a group layout w/o non-padding elements is not-supported. With the current text, if there's no non-padding element, then it is not clear how should the other rules be applied.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2363186763

From mcimadamore at openjdk.org  Fri Sep 20 08:52:48 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Sep 2024 08:52:48 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
Message-ID: <I-UJVlTAQwhlE4nXETiFJibY0F3-SwWBzXg4QJW5WQs=.3a4edd35-7948-4098-9004-d281874f0733@github.com>

On Thu, 19 Sep 2024 21:25:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

> > And I claim that this is outside the scope of this PR.
> 
> And I strongly disagree because the only reason I conceded that this documentation issue need not be addressed by the CSR request for JEP 472 was because JDK-8338596 was filed to address it - ref the comment from @jddarcy : https://bugs.openjdk.org/browse/JDK-8331672?focusedId=14699206&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699206



> > And I claim that this is outside the scope of this PR.
> 
> And I strongly disagree because the only reason I conceded that this documentation issue need not be addressed by the CSR request for JEP 472 was because JDK-8338596 was filed to address it - ref the comment from @jddarcy : https://bugs.openjdk.org/browse/JDK-8331672?focusedId=14699206&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699206

Just be clarify: is it your expectation that, in order for this issue to be fixed, we should fix the javadoc of *all* caller sensitive methods, addressing issues that have nothing to do with restricted-ness? If so, then my reading of this issue was incorrect, I will close this PR, and file a separate, more targeted, issue to improve the situation of restricted methods only (which is the goal of this PR).

Separately, while I agree that the javadoc for caller sensitive methods is lacking in many ways, I don't see the connection between correctly specifying what classloader is used in `System.loadLibrary` and JEP 472. That is, that javadoc issue has been there before JEP 472 - and unaffected by it. Restrictedness, on the other hand, adds a new dimension (and this is indeed new in JEP 472, at least for some of the methods outside FFM), so it makes sense to say: now we have to say what happens when restricted methods are called and there's no Java class in the caller stack.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2363200566

From mdoerr at openjdk.org  Fri Sep 20 09:18:35 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Sep 2024 09:18:35 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <kmmCNy8XoR53lE9MAkHHcE3g6zwFKlpa9JQxgxPB1nQ=.ccecfefc-7b3f-482b-afe8-e023dfb39f31@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21082#pullrequestreview-2317719288

From redestad at openjdk.org  Fri Sep 20 09:23:47 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Sep 2024 09:23:47 GMT
Subject: RFR: 8340456: Reduce overhead of proxying Object methods in
 ProxyGenerator
In-Reply-To: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
References: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
Message-ID: <q9np0ovPwMQag1MvgZlfKEiB1uggpdJdDWwFFl-P6tc=.0cb491f0-a4ad-44e7-82da-1918294647f0@github.com>

On Thu, 19 Sep 2024 14:08:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR changes proxy code gen to avoid generating `Class.forName("java.lang.Object")`, instead emitting an ldc for the class literal, `ldc(CD_Object)`, java code equivalent `Object.class`. 
> 
> More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from `InvokerBytecodeGenerator.isStaticallyInvocable`, but just addressing the `Object` methods gets rid of most `Class.forName` emits. It's not terribly important for throughput performance since these are called in the generated `clinit`, so getting a quick win with few additional checks is a good starting point.
> 
> Added a few unrelated minor refactors/improvements, guided by diagnostic runs of the now fixed microbenchmark.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21090#issuecomment-2363263160

From redestad at openjdk.org  Fri Sep 20 09:23:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Sep 2024 09:23:48 GMT
Subject: Integrated: 8340456: Reduce overhead of proxying Object methods in
 ProxyGenerator
In-Reply-To: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
References: <f4ry39Nd1i7Z-GBWh6DpboYeWva4eYnq92ROTeiFPXw=.43589f6a-4465-431e-a5cc-04e312138a4b@github.com>
Message-ID: <N2bfm-Z3_G9rLh60tDf8x6IhjQXkgZzjSAI89anvDO8=.43aed43d-e0df-4acc-a1b3-68df23f00b9d@github.com>

On Thu, 19 Sep 2024 14:08:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR changes proxy code gen to avoid generating `Class.forName("java.lang.Object")`, instead emitting an ldc for the class literal, `ldc(CD_Object)`, java code equivalent `Object.class`. 
> 
> More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from `InvokerBytecodeGenerator.isStaticallyInvocable`, but just addressing the `Object` methods gets rid of most `Class.forName` emits. It's not terribly important for throughput performance since these are called in the generated `clinit`, so getting a quick win with few additional checks is a good starting point.
> 
> Added a few unrelated minor refactors/improvements, guided by diagnostic runs of the now fixed microbenchmark.

This pull request has now been integrated.

Changeset: a50440fa
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a50440fadcd1aa9d8bfddc153dbde6fd55ceb9fa
Stats:     327 lines in 4 files changed: 146 ins; 166 del; 15 mod

8340456: Reduce overhead of proxying Object methods in ProxyGenerator

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21090

From jvernee at openjdk.org  Fri Sep 20 10:27:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Sep 2024 10:27:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddindLayout
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <a_Iwi_RFVy_RVnpnLTLYRfkJJNUUNF3BaJGfOyZWt1A=.f45e5c37-6cda-4cf9-b46e-a539f4d33e6e@github.com>

On Tue, 17 Sep 2024 14:12:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR prevents sequence layout with padding to be used with the Linker.

src/java.base/share/classes/java/lang/foreign/Linker.java line 252:

> 250:  * <li>the alignment constraint of {@code S} is set to its
> 251:  *     <a href="MemoryLayout.html#layout-align">natural alignment</a>, and</li>
> 252:  * <li>{@code S.elementLayout()} is not a padding layout.</li>

I think the existing text already covers this case, so no addition should be needed. Padding layouts on their own are not supported layouts. (Note e.g. how for group layouts we say: 'each member layout ... is either a padding layout or a layout supported by {@code NL}'.

Though, either way we'll need a CSR for the behavior change.

test/jdk/java/foreign/TestLinker.java line 165:

> 163:         FunctionDescriptor fd = FunctionDescriptor.of(struct, struct);
> 164:         Linker linker = Linker.nativeLinker();
> 165:         assertThrows(IllegalArgumentException.class, () -> linker.downcallHandle(fd));

Could you please verify the exception message here as well? (Since there are multiple IAEs possible)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1768366549
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1768363927

From jvernee at openjdk.org  Fri Sep 20 10:36:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Sep 2024 10:36:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddindLayout
In-Reply-To: <xCK_7Wp_fHgT4ZJ3-vs8qQ3V1vxGQdxfCudLbWWQvWA=.8b1a969c-b70b-4438-bac7-14dd3a2b1005@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <xCK_7Wp_fHgT4ZJ3-vs8qQ3V1vxGQdxfCudLbWWQvWA=.8b1a969c-b70b-4438-bac7-14dd3a2b1005@github.com>
Message-ID: <RvHeqvFUg31Ss9F5-F9Bz8nDTpgUNa2Gr4yldyc25UE=.7f940ef4-0d17-4669-ba20-544b0c4a4eaf@github.com>

On Fri, 20 Sep 2024 08:41:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The javadoc of the `Linker` also states that:
> 
> > [A group layout] G does not contain padding other than what is strictly required to align
> > its non-padding layout elements, or to satisfy (2) [the size of {@code G} is a multiple of its alignment constraint]
> 
> I believe it is the intent here to rule out empty groups, or groups that contain only padding. Should we address that here (as I believe that once we add more checks, we'll need more tweaks to make the various exception more uniform) ?

Empty structs are supported by GCC, and the size of such a struct is actually 0 bytes in C (as opposed to C++): https://godbolt.org/z/hvoc88oE7 So they should be allowed I think. (We don't currently reject them at least)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2363402197

From mcimadamore at openjdk.org  Fri Sep 20 11:16:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Sep 2024 11:16:34 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddindLayout
In-Reply-To: <RvHeqvFUg31Ss9F5-F9Bz8nDTpgUNa2Gr4yldyc25UE=.7f940ef4-0d17-4669-ba20-544b0c4a4eaf@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <xCK_7Wp_fHgT4ZJ3-vs8qQ3V1vxGQdxfCudLbWWQvWA=.8b1a969c-b70b-4438-bac7-14dd3a2b1005@github.com>
 <RvHeqvFUg31Ss9F5-F9Bz8nDTpgUNa2Gr4yldyc25UE=.7f940ef4-0d17-4669-ba20-544b0c4a4eaf@github.com>
Message-ID: <RSuT_1npYNkiUiKCQLQK72tmQ0V0k1hxktcfndfQJ3U=.3d5f0fa7-99dc-417b-ad2f-418b97a7fe57@github.com>

On Fri, 20 Sep 2024 10:32:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > The javadoc of the `Linker` also states that:
> > > [A group layout] G does not contain padding other than what is strictly required to align
> > > its non-padding layout elements, or to satisfy (2) [the size of {@code G} is a multiple of its alignment constraint]
> > 
> > 
> > I believe it is the intent here to rule out empty groups, or groups that contain only padding. Should we address that here (as I believe that once we add more checks, we'll need more tweaks to make the various exception more uniform) ?
> 
> Empty structs are supported by GCC, and the size of such a struct is actually 0 bytes in C (as opposed to C++): https://godbolt.org/z/hvoc88oE7 So they should be allowed I think. (We don't currently reject them at least)

OK - but I still think that padding-only groups should still be rejected. They feel outside the boundary of what the javadoc says - and yet, one could construct an argument that the current javadoc doesn't explicitly disallow them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2363474735

From jpai at openjdk.org  Fri Sep 20 12:36:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Sep 2024 12:36:07 GMT
Subject: RFR: 8340537: Typo in javadoc of java.util.jar.JarFile
Message-ID: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>

Can I please get a review of this trivial typo fix in `JarFile` class' javadoc?

-------------

Commit messages:
 - 8340537: Typo in javadoc of java.util.jar.JarFile

Changes: https://git.openjdk.org/jdk/pull/21108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340537
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21108/head:pull/21108

PR: https://git.openjdk.org/jdk/pull/21108

From mullan at openjdk.org  Fri Sep 20 12:48:35 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Sep 2024 12:48:35 GMT
Subject: RFR: 8340537: Typo in javadoc of java.util.jar.JarFile
In-Reply-To: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
References: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
Message-ID: <ROx-aEG2RsP5foYn9HnlOhP83tgDzqPsrFWpWNliGQM=.c83d5f94-771f-4d89-b94f-97b077236b35@github.com>

On Fri, 20 Sep 2024 12:30:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial typo fix in `JarFile` class' javadoc?

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21108#pullrequestreview-2318183860

From lancea at openjdk.org  Fri Sep 20 13:15:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Sep 2024 13:15:38 GMT
Subject: RFR: 8340537: Typo in javadoc of java.util.jar.JarFile
In-Reply-To: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
References: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
Message-ID: <kpX8DFN-WJ0MxR1MRHao2kJVoWJMMMzRU8n-wvPbhII=.ad4f810e-15aa-4fb7-bad3-458652e0724f@github.com>

On Fri, 20 Sep 2024 12:30:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial typo fix in `JarFile` class' javadoc?

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21108#pullrequestreview-2318248221

From nbenalla at openjdk.org  Fri Sep 20 14:02:14 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 20 Sep 2024 14:02:14 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v15]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <jrUNyuO71nVf9r_jcX9Mgl-XZuSi8jiCsbo2VvDG024=.a46d6da5-e82d-4b4c-8a91-980045f88704@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - exclude list is now module specific
 - remove empty if statement, debugging showed the condition is never true
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Change "found" to "should be" in the error messages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - avoid using `continue`, fix mistake in last commit
 - extend SinceChecker to now skip some packages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - ... and 21 more: https://git.openjdk.org/jdk/compare/3c22d83c...62a34064

-------------

Changes: https://git.openjdk.org/jdk/pull/18934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=14
  Stats: 983 lines in 3 files changed: 981 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From archie.cobbs at gmail.com  Fri Sep 20 14:32:45 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 20 Sep 2024 09:32:45 -0500
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <54269739-3040-4676-8D36-0363357CB151@gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
 <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>
 <54269739-3040-4676-8D36-0363357CB151@gmail.com>
Message-ID: <CANSoFxvT2J81yhsz1D3ui-yJTgMOZivtD+18frUcZTO48HAQyA@mail.gmail.com>

Hi Kim,

Here is a quick summary of my thoughts...

Before diving into coding solutions, we need to make sure we're all on the
same page.

First: (Viktor) Do we all agree that "Interpretation B" accurately
describes how things are actually working today?

If "No" then we need to stop and understand the disagreement.

If "Yes" then the next step is to collectively decide what, if anything, we
might want to change. Here are some options:

   1. Do nothing
   2. Do nothing but document the behavior more clearly in the Javadoc
   3. Change the behavior from B ? A and update the Javadoc accordingly
   4. Something else?

Deciding among 1-4 will likely need to involve more core-libs-dev people,
especially of the java.util.concurrent ilk.

-Archie

On Fri, Sep 20, 2024 at 1:58?AM ??? <miiiinju00 at gmail.com> wrote:

> Hi Viktor, Archie, and Daniel,
>
> I hope everything is going well on your end. I really appreciate the
> thoughtful feedback you've provided so far, and I wanted to follow up on
> our previous discussion about the potential fairness issue in
> ArrayBlockingQueue when using ReentrantLock with Condition.await().
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240920/cc21d8e2/attachment.htm>

From swen at openjdk.org  Fri Sep 20 14:39:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Sep 2024 14:39:44 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg
Message-ID: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>

CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.

-------------

Commit messages:
 - optimize setLocalsFromArg

Changes: https://git.openjdk.org/jdk/pull/21106/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21106&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340544
  Stats: 27 lines in 1 file changed: 8 ins; 5 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21106/head:pull/21106

PR: https://git.openjdk.org/jdk/pull/21106

From viktor.klang at oracle.com  Fri Sep 20 15:16:49 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 20 Sep 2024 15:16:49 +0000
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxvT2J81yhsz1D3ui-yJTgMOZivtD+18frUcZTO48HAQyA@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
 <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>
 <54269739-3040-4676-8D36-0363357CB151@gmail.com>
 <CANSoFxvT2J81yhsz1D3ui-yJTgMOZivtD+18frUcZTO48HAQyA@mail.gmail.com>
Message-ID: <MW4PR10MB5774FACF332B45025D7FD245FF6C2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Archie and Kim,

Thank you for your patience, I tried to get back to this as soon as possible.

Trying to swap this in again, looking at the code it would seem like lockInterruptibly() by external threads can indeed get interleaved with signaled waiters in the Condition's wait list.

It is worth noting, however, that you could have any number of different Conditions operating within the same lock, so the question would be what the relative priority should be between the different waiters within the different Conditions, esp. in the face of competition from "the outside".

Before we do anything at all, does there exist a reproducer which would illustrate that the current behavior causes problems?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Archie Cobbs <archie.cobbs at gmail.com>
Sent: Friday, 20 September 2024 16:32
To: ??? <miiiinju00 at gmail.com>
Cc: Viktor Klang <viktor.klang at oracle.com>; Daniel FUCHS <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim,

Here is a quick summary of my thoughts...

Before diving into coding solutions, we need to make sure we're all on the same page.

First: (Viktor) Do we all agree that "Interpretation B" accurately describes how things are actually working today?

If "No" then we need to stop and understand the disagreement.

If "Yes" then the next step is to collectively decide what, if anything, we might want to change. Here are some options:

  1.  Do nothing
  2.  Do nothing but document the behavior more clearly in the Javadoc
  3.  Change the behavior from B ? A and update the Javadoc accordingly
  4.  Something else?

Deciding among 1-4 will likely need to involve more core-libs-dev people, especially of the java.util.concurrent ilk.

-Archie

On Fri, Sep 20, 2024 at 1:58?AM ??? <miiiinju00 at gmail.com<mailto:miiiinju00 at gmail.com>> wrote:

Hi Viktor, Archie, and Daniel,

I hope everything is going well on your end. I really appreciate the thoughtful feedback you've provided so far, and I wanted to follow up on our previous discussion about the potential fairness issue in ArrayBlockingQueue when using ReentrantLock with Condition.await().

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240920/1598a8e5/attachment-0001.htm>

From liach at openjdk.org  Fri Sep 20 15:28:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Sep 2024 15:28:36 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg
In-Reply-To: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
Message-ID: <x6WoR3tPm7YiVgjtyDvps_nAAkYF7ZnTfGpP7IPE0U0=.adf90bff-ef96-40cc-8d83-50a629dcffa3@github.com>

On Fri, 20 Sep 2024 09:18:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.

Looks good. Using `Util.parameterSlots` avoids redundant array allocation and copies. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21106#issuecomment-2363986573

From archie.cobbs at gmail.com  Fri Sep 20 15:37:03 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 20 Sep 2024 10:37:03 -0500
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <MW4PR10MB5774FACF332B45025D7FD245FF6C2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
 <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>
 <54269739-3040-4676-8D36-0363357CB151@gmail.com>
 <CANSoFxvT2J81yhsz1D3ui-yJTgMOZivtD+18frUcZTO48HAQyA@mail.gmail.com>
 <MW4PR10MB5774FACF332B45025D7FD245FF6C2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CANSoFxvANo6SZ8ig8ChOeRqBbN0cG4KUoZjTVEQmCKKJDpRGwg@mail.gmail.com>

On Fri, Sep 20, 2024 at 10:16?AM Viktor Klang <viktor.klang at oracle.com>
wrote:

> Before we do anything at all, does there exist a reproducer which would
> illustrate that the current behavior causes problems?
>

I believe this is the most recent one:
https://mail.openjdk.org/pipermail/core-libs-dev/2024-September/129031.html

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240920/f1fb78a0/attachment.htm>

From asotona at openjdk.org  Fri Sep 20 15:41:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 20 Sep 2024 15:41:39 GMT
Subject: RFR: 8339198: Remove tag field from AbstractPoolEntry
In-Reply-To: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
References: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
Message-ID: <rD32Z2qopKIqKJg5OHZBwqVvQVmO80qt8OGA2X_ir4k=.8c46af8f-2e0f-4b34-9ca7-4ce28a164fe0@github.com>

On Thu, 19 Sep 2024 17:07:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> The `tag` field in `AbstractPoolEntry` is redundant, as it's always of the same value for each subtype. This is now replaced with an override. This can reduce the footprint of the entries..
> 
> The removal of `hash` was considered but withdrawn; in part because hash computations are heavy; in c2 things as simple as identity hash code are better stored in object fields for performance.

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21093#pullrequestreview-2318634277

From miiiinju00 at gmail.com  Fri Sep 20 15:43:28 2024
From: miiiinju00 at gmail.com (=?utf-8?B?6rmA66+87KO8?=)
Date: Sat, 21 Sep 2024 00:43:28 +0900
Subject: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in
 BlockingQueue under high contention and suggestion for fair mode in
 ArrayBlockingQueue and LinkedBlockingQueue
In-Reply-To: <CANSoFxvANo6SZ8ig8ChOeRqBbN0cG4KUoZjTVEQmCKKJDpRGwg@mail.gmail.com>
References: <CABur-aFQ1jkLe1wA+UmM02-JUsNw-=Q65bP5c=PAVwDm4bpeXg@mail.gmail.com>
 <b9f08e53-5eed-492e-820f-a7925bd66a34@oracle.com>
 <CABur-aEPdiPh-i2jZ2jrM6DaXdNRyDYCav-qxhGS53hiPiEgqg@mail.gmail.com>
 <c5454674-b3e6-4699-808d-25d2cacc0fff@oracle.com>
 <C6EA7027-702C-4188-95C4-B2E1D5702F86@gmail.com>
 <898e69d5-68c0-4a3e-8d5b-bce56ffd48c3@oracle.com>
 <MW4PR10MB5774F6D9B5D6BB5A26BD23D7FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aHU6rbJf7e2PpycOzfm-23Pfav53gdE=hPWy6ZQDbZQ0g@mail.gmail.com>
 <CANSoFxuAzzATVkF3xoAN-uwkNOxxBdVrFbMzLe47U8h3u_Wq8A@mail.gmail.com>
 <MW4PR10MB5774646BF9431F68AF361482FF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxtVm3L+bB=DoEa3fx90BBN1eATN0t51ajRQO6783-xtPw@mail.gmail.com>
 <MW4PR10MB57744B6AA387F33FEBF7DF6AFF9D2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CABur-aFYxZ+fErWrZCCCu5CMT6P7UwGBWEWpnAjvDWChLu44vQ@mail.gmail.com>
 <MW4PR10MB57745735757C119D30DCDA16FF9E2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <538390BC-B783-495E-A9C5-6F886128704E@gmail.com>
 <50A9E02F-D8E4-4E27-B3C6-EC1B796B423A@gmail.com>
 <CANSoFxuv-juTcWYCt-mERm+9jp40X_ZYvofr=KnMUpaG2zvocA@mail.gmail.com>
 <F5F35C3B-BD5C-4177-8040-134E52A6A69B@gmail.com>
 <CANSoFxvXwFmGL4C-X2px9rxq6716NoRaZ+6CC2jzB0HzP1HLGA@mail.gmail.com>
 <A452AF40-0B75-435A-99BF-E9D69644B1BA@gmail.com>
 <54269739-3040-4676-8D36-0363357CB151@gmail.com>
 <CANSoFxvT2J81yhsz1D3ui-yJTgMOZivtD+18frUcZTO48HAQyA@mail.gmail.com>
 <MW4PR10MB5774FACF332B45025D7FD245FF6C2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CANSoFxvANo6SZ8ig8ChOeRqBbN0cG4KUoZjTVEQmCKKJDpRGwg@mail.gmail.com>
Message-ID: <5748E5F6-18C6-4BB1-A092-CB42D17BF47D@gmail.com>

Hi Archie, and Viktor

Thank you very much for your response and for referencing the test case I shared earlier.

I can confirm that the test case is accurate, and the issue lies in the explanation I provided below it. Upon reflection, I realized that certain parts of my explanation were incorrect. I?ve since made the necessary corrections, which you can find in my follow-up email. If you could kindly review the updated explanation along with the test case, I would greatly appreciate it.

Here?s the link to the corrected explanation: https://mail.openjdk.org/pipermail/core-libs-dev/2024-September/129085.html

Thank you again for your time and understanding.

Best regards,

Minju Kim



> 2024. 9. 21. ?? 12:37, Archie Cobbs <archie.cobbs at gmail.com> ??:
> 
> On Fri, Sep 20, 2024 at 10:16?AM Viktor Klang <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>> wrote:
>> Before we do anything at all, does there exist a reproducer which would illustrate that the current behavior causes problems?
> 
> I believe this is the most recent one: https://mail.openjdk.org/pipermail/core-libs-dev/2024-September/129031.html
> 
> -Archie
> 
> --
> Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240921/0ad1280d/attachment-0001.htm>

From lancea at openjdk.org  Fri Sep 20 15:54:12 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Sep 2024 15:54:12 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v3]
In-Reply-To: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
Message-ID: <1WCK4NwQu9fhihVBbwqw-3Up9mkxlVafoLkqE1UEUUw=.52d0ab3d-a36b-4f84-bb04-0fe4d709014f@github.com>

> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
> 
> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
> 
> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updated javadoc based on last round of input

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21003/files
  - new: https://git.openjdk.org/jdk/pull/21003/files/04c723d1..69cf3312

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=01-02

  Stats: 13 lines in 2 files changed: 0 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21003/head:pull/21003

PR: https://git.openjdk.org/jdk/pull/21003

From redestad at openjdk.org  Fri Sep 20 15:55:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Sep 2024 15:55:37 GMT
Subject: RFR: 8339198: Remove tag field from AbstractPoolEntry
In-Reply-To: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
References: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
Message-ID: <NtB6FxMbbK1WeWxmJiq9T_rNC3fii28Mo2Y7k3QwyNE=.b61e9e88-2459-4a73-a7d2-fc9078675f29@github.com>

On Thu, 19 Sep 2024 17:07:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> The `tag` field in `AbstractPoolEntry` is redundant, as it's always of the same value for each subtype. This is now replaced with an override. This can reduce the footprint of the entries..
> 
> The removal of `hash` was considered but withdrawn; in part because hash computations are heavy; in c2 things as simple as identity hash code are better stored in object fields for performance.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21093#pullrequestreview-2318678218

From iris at openjdk.org  Fri Sep 20 15:57:34 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 20 Sep 2024 15:57:34 GMT
Subject: RFR: 8340537: Typo in javadoc of java.util.jar.JarFile
In-Reply-To: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
References: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
Message-ID: <TG5JW8rwxd4x6DpiQ27PwXU9YZP8SiMZirtoWheGUPQ=.b18add41-61ff-4170-b0a4-960f8c3a0984@github.com>

On Fri, 20 Sep 2024 12:30:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial typo fix in `JarFile` class' javadoc?

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21108#pullrequestreview-2318683971

From jpai at openjdk.org  Fri Sep 20 16:05:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Sep 2024 16:05:39 GMT
Subject: RFR: 8340537: Typo in javadoc of java.util.jar.JarFile
In-Reply-To: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
References: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
Message-ID: <jJH7mqdDO3X5fHYHe73AkSwVpW68PVIZAuIYJrhGwk8=.c53a4870-1ffc-4582-8ca5-59c18853bb1d@github.com>

On Fri, 20 Sep 2024 12:30:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial typo fix in `JarFile` class' javadoc?

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21108#issuecomment-2364052197

From jpai at openjdk.org  Fri Sep 20 16:05:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Sep 2024 16:05:39 GMT
Subject: Integrated: 8340537: Typo in javadoc of java.util.jar.JarFile
In-Reply-To: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
References: <J82ysaF4UDiUB6ZDg68ioXCG0oAqNcCnV68qOKujy4E=.c8b8aad4-fdda-4316-8acf-449a36a4c3de@github.com>
Message-ID: <E9D8k04D9CcJVuwNieEHnaxKMMjsotMjyjbRq0ZAUDY=.c9aba824-8daf-4628-ac31-634cf4d40f04@github.com>

On Fri, 20 Sep 2024 12:30:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial typo fix in `JarFile` class' javadoc?

This pull request has now been integrated.

Changeset: 90d3a64b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90d3a64b0afd5810981287b174c6687f0f604f36
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8340537: Typo in javadoc of java.util.jar.JarFile

Reviewed-by: mullan, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/21108

From rriggs at openjdk.org  Fri Sep 20 16:14:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Sep 2024 16:14:38 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v7]
In-Reply-To: <RA9VMXnwmsFAOcCscNjIs2dmx3hYPQAbbJ0HfUje5SY=.e2de3ec3-41cc-4627-a3b3-265f9c96be1c@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <RA9VMXnwmsFAOcCscNjIs2dmx3hYPQAbbJ0HfUje5SY=.e2de3ec3-41cc-4627-a3b3-265f9c96be1c@github.com>
Message-ID: <7MJxg_rS9YTysPR7WLIMT7SF__DNazV5DtgNqh0goyU=.3117eb70-70aa-4029-90c3-432175c5aece@github.com>

On Fri, 20 Sep 2024 08:14:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change

Looks good.

The current (MhUtil) source is easier to read. 
So unless ConstantBootstraps could have an equivalent (simple) API that evaluates to a DynamicConstant, keep what you have.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20972#pullrequestreview-2318714294
PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2364070043

From liach at openjdk.org  Fri Sep 20 16:14:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Sep 2024 16:14:40 GMT
Subject: RFR: 8339198: Remove tag field from AbstractPoolEntry
In-Reply-To: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
References: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
Message-ID: <Rql5T6AZHWStM5x1FLxfc5B9kr5ruBXxg5nxGuo8rTo=.93eb1a3b-3153-4286-8cf3-70faeed13d1e@github.com>

On Thu, 19 Sep 2024 17:07:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> The `tag` field in `AbstractPoolEntry` is redundant, as it's always of the same value for each subtype. This is now replaced with an override. This can reduce the footprint of the entries..
> 
> The removal of `hash` was considered but withdrawn; in part because hash computations are heavy; in c2 things as simple as identity hash code are better stored in object fields for performance.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21093#issuecomment-2364068134

From liach at openjdk.org  Fri Sep 20 16:14:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Sep 2024 16:14:40 GMT
Subject: Integrated: 8339198: Remove tag field from AbstractPoolEntry
In-Reply-To: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
References: <fWtkeYSOVQzzONQ_CSZl41BpEaMdME19a5a-_FGJEWo=.45324eea-558f-4d94-b48b-ab2ba8d62207@github.com>
Message-ID: <0XYM3JhQFmZ280nHu4KXLOrFsTlDY7V-I-lkhMfBfiQ=.6b59cf88-3a41-4f4a-8bd9-cc9fb98f3950@github.com>

On Thu, 19 Sep 2024 17:07:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> The `tag` field in `AbstractPoolEntry` is redundant, as it's always of the same value for each subtype. This is now replaced with an override. This can reduce the footprint of the entries..
> 
> The removal of `hash` was considered but withdrawn; in part because hash computations are heavy; in c2 things as simple as identity hash code are better stored in object fields for performance.

This pull request has now been integrated.

Changeset: ab81197d
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab81197d0ded93b82eea9f8fb35d1647c4520f1e
Stats:     140 lines in 1 file changed: 97 ins; 4 del; 39 mod

8339198: Remove tag field from AbstractPoolEntry

Reviewed-by: asotona, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/21093

From redestad at openjdk.org  Fri Sep 20 16:16:38 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Sep 2024 16:16:38 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg
In-Reply-To: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
Message-ID: <IOXzBDzsvGNmeQIWp3otLpO4fxuLLbNlqKitH6XJruU=.b7e66155-2b7b-4774-aa0d-186ca9357df1@github.com>

On Fri, 20 Sep 2024 09:18:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.

LGTM

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1069:

> 1067:                     localsSize += 2;
> 1068:                 } else {
> 1069:                     if (desc == CD_int || desc == CD_boolean || desc == CD_byte || desc == CD_char || desc == CD_short) {

An alternative would be `if (!desc.isPrimitive()) { .. } else if (desc == CD_float) { .. } else { /* INTEGER_TYPE */ }` - might be more compact at least.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21106#pullrequestreview-2318716350
PR Review Comment: https://git.openjdk.org/jdk/pull/21106#discussion_r1768877913

From liach at openjdk.org  Fri Sep 20 16:29:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Sep 2024 16:29:34 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg
In-Reply-To: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
Message-ID: <755z086T3Rn_2beh7Xcr_FkkupgP7MD5YUjQTF8zaCE=.5328ca4d-b492-486b-b83b-8b90b76bea84@github.com>

On Fri, 20 Sep 2024 09:18:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.

Tier 1-3 tests pass.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21106#pullrequestreview-2318737715

From liach at openjdk.org  Fri Sep 20 16:29:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Sep 2024 16:29:35 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg
In-Reply-To: <IOXzBDzsvGNmeQIWp3otLpO4fxuLLbNlqKitH6XJruU=.b7e66155-2b7b-4774-aa0d-186ca9357df1@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
 <IOXzBDzsvGNmeQIWp3otLpO4fxuLLbNlqKitH6XJruU=.b7e66155-2b7b-4774-aa0d-186ca9357df1@github.com>
Message-ID: <KT0iM_qG92jsM042xY9LfRJfX0uV9KLJGUJfsO2Hbfo=.087c8114-38d4-477e-996a-92c48fd33c30@github.com>

On Fri, 20 Sep 2024 16:13:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1069:
> 
>> 1067:                     localsSize += 2;
>> 1068:                 } else {
>> 1069:                     if (desc == CD_int || desc == CD_boolean || desc == CD_byte || desc == CD_char || desc == CD_short) {
> 
> An alternative would be `if (!desc.isPrimitive()) { .. } else if (desc == CD_float) { .. } else { /* INTEGER_TYPE */ }` - might be more compact at least.

I think wenshao is intentionally avoiding `isPrimitive` as it is slower; we can fix that later I guess.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21106#discussion_r1768891745

From swen at openjdk.org  Fri Sep 20 16:35:07 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Sep 2024 16:35:07 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg [v2]
In-Reply-To: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
Message-ID: <ACnTTe6Oqx87t93koDr1pgKl4sSDpITuNM-y9KFkHY8=.65614756-328f-4332-85d2-f3096139be34@github.com>

> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  more compact

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21106/files
  - new: https://git.openjdk.org/jdk/pull/21106/files/9d554f11..7d71290b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21106&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21106&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21106/head:pull/21106

PR: https://git.openjdk.org/jdk/pull/21106

From swen at openjdk.org  Fri Sep 20 16:37:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Sep 2024 16:37:37 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg [v2]
In-Reply-To: <IOXzBDzsvGNmeQIWp3otLpO4fxuLLbNlqKitH6XJruU=.b7e66155-2b7b-4774-aa0d-186ca9357df1@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
 <IOXzBDzsvGNmeQIWp3otLpO4fxuLLbNlqKitH6XJruU=.b7e66155-2b7b-4774-aa0d-186ca9357df1@github.com>
Message-ID: <4u9KyoyubBYNbT1jCBQDeRhODAcODSCjIm3iEwzWPT0=.c2adcac9-378f-44e6-a1de-b7535d3cdd36@github.com>

On Fri, 20 Sep 2024 16:13:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more compact
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1069:
> 
>> 1067:                     localsSize += 2;
>> 1068:                 } else {
>> 1069:                     if (desc == CD_int || desc == CD_boolean || desc == CD_byte || desc == CD_char || desc == CD_short) {
> 
> An alternative would be `if (!desc.isPrimitive()) { .. } else if (desc == CD_float) { .. } else { /* INTEGER_TYPE */ }` - might be more compact at least.

because ClassDesc permits PrimitiveClassDescImpl & ReferenceClassDescImpl, based on @cl4es 's suggestion, I used `instanceof ReferenceClassDescImpl` instead of `!isPrimitive()`, and now codeSize becomes 239

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21106#discussion_r1768900873

From liach at openjdk.org  Fri Sep 20 16:38:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Sep 2024 16:38:39 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v6]
In-Reply-To: <r9skwi26EuGlQR8LniR4cwBL4DCkcNQHwjZSPiq0EAs=.5d8123bf-9fe0-46da-862d-31343134a661@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <r9skwi26EuGlQR8LniR4cwBL4DCkcNQHwjZSPiq0EAs=.5d8123bf-9fe0-46da-862d-31343134a661@github.com>
Message-ID: <LpjUBLywp6lvgoUBjeg8drKAeYLRA29df0UxRyrk0HM=.b2cce8de-251f-467e-b758-6eba01c9282f@github.com>

On Fri, 20 Sep 2024 05:09:19 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix for write long utf

Tier 1-3 tests look good

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20886#pullrequestreview-2318757166

From asemenyuk at openjdk.org  Fri Sep 20 16:46:37 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Sep 2024 16:46:37 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
Message-ID: <7PeKLVujnLzcw7MnNKTwA3KshanIucfEkMRWMjtNMes=.0234eb8b-490c-447e-9f3b-c2881b5e9b33@github.com>

On Fri, 20 Sep 2024 02:53:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redo removal of `resource.wxl-file-name` property
>  - Revert "8338918: Remove non translated file name from WinResources resource bundle"
>    
>    This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.

@sashamatveev @justin-curtis-lu please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21100#issuecomment-2364121153

From jbhateja at openjdk.org  Fri Sep 20 17:04:41 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 20 Sep 2024 17:04:41 GMT
Subject: RFR: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes [v4]
In-Reply-To: <Dn3kYpqZ1K-y5ToZT_8UXpTCVgvs_Grepf9OwmybEdY=.1ce7bf07-f85f-4f50-81bf-e3353ffac8b7@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
 <Dn3kYpqZ1K-y5ToZT_8UXpTCVgvs_Grepf9OwmybEdY=.1ce7bf07-f85f-4f50-81bf-e3353ffac8b7@github.com>
Message-ID: <V0jjWx4SsyFt-Oo8zVS44ykvZI-_l2X_ybjtotjEJx0=.5cb1d040-3dfd-4cde-b09c-0b9687c79580@github.com>

On Thu, 19 Sep 2024 21:43:01 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>> 
>> Summary of changes is as follows:
>>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>> 
>> For the following source:
>> 
>> 
>>     public void test() {
>>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>>             index.selectFrom(inpvect).intoArray(byteres, j);
>>         }
>>     }
>> 
>> 
>> The code generated for inner main now looks as follows:
>> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>>   0x00007f40d02274d0:   movslq %ebx,%r13
>>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>>   0x00007f40d022751f:   add    $0x40,%ebx
>>   0x00007f40d0227522:   cmp    %r8d,%ebx
>>   0x00007f40d0227525:   jl     0x00007f40d02274d0
>> 
>> Best Regards,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review comments

Thanks @sviswa7 , LGTM

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20634#pullrequestreview-2318802240

From jwaters at openjdk.org  Fri Sep 20 17:05:36 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 20 Sep 2024 17:05:36 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <PHG2tW8g4qwVEjY3455opRlSBo-0iIu3rxX68imR_8s=.23d7b8ea-dbda-4c36-b758-75a0a2177e47@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

Windows changes look good to me (No idea why I specify Windows changes when all the code in this PR are Windows changes)

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21082#pullrequestreview-2318803035

From jlu at openjdk.org  Fri Sep 20 17:10:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Sep 2024 17:10:36 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
Message-ID: <Rc2CIJcNy1CQBGeuWnkoEqfDovv7ZJQMgcENC0QJAbg=.1ae43eb4-2930-484b-9c40-3aa8a828934f@github.com>

On Fri, 20 Sep 2024 02:53:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redo removal of `resource.wxl-file-name` property
>  - Revert "8338918: Remove non translated file name from WinResources resource bundle"
>    
>    This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.

SHARED and PLATFORM bundles combined into BUNDLE, which now includes the NoL10N resources for Windows.
This ensures the `resource.wxl-file-name` key/val is no longer localized.

LGTM. Thanks for handling this change.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21100#pullrequestreview-2318812462

From redestad at openjdk.org  Fri Sep 20 17:10:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Sep 2024 17:10:37 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg [v2]
In-Reply-To: <4u9KyoyubBYNbT1jCBQDeRhODAcODSCjIm3iEwzWPT0=.c2adcac9-378f-44e6-a1de-b7535d3cdd36@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
 <IOXzBDzsvGNmeQIWp3otLpO4fxuLLbNlqKitH6XJruU=.b7e66155-2b7b-4774-aa0d-186ca9357df1@github.com>
 <4u9KyoyubBYNbT1jCBQDeRhODAcODSCjIm3iEwzWPT0=.c2adcac9-378f-44e6-a1de-b7535d3cdd36@github.com>
Message-ID: <qEjtKtIL_ClWlntXS5WubQodHnrSfCaDoI8XPPi3epg=.13c87ab4-83bf-400f-bf86-ad5260e0ad34@github.com>

On Fri, 20 Sep 2024 16:35:05 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1069:
>> 
>>> 1067:                     localsSize += 2;
>>> 1068:                 } else {
>>> 1069:                     if (desc == CD_int || desc == CD_boolean || desc == CD_byte || desc == CD_char || desc == CD_short) {
>> 
>> An alternative would be `if (!desc.isPrimitive()) { .. } else if (desc == CD_float) { .. } else { /* INTEGER_TYPE */ }` - might be more compact at least.
>
> because ClassDesc permits PrimitiveClassDescImpl & ReferenceClassDescImpl, based on @cl4es 's suggestion, I used `instanceof ReferenceClassDescImpl` instead of `!isPrimitive()`, and now codeSize becomes 239

Great! Yeah, overrides of `isPrimitive` would probably be overall better than the current default method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21106#discussion_r1768935058

From archie.cobbs at gmail.com  Fri Sep 20 17:20:24 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 20 Sep 2024 12:20:24 -0500
Subject: Stream Gatherers (JEP 473) feedback
In-Reply-To: <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
Message-ID: <CANSoFxsGW78wGHG2MS3PKXPUSmT1hyT4ViBOTxx9pMEvMeXnLg@mail.gmail.com>

Hi Viktor,

I recently encountered a real-world use case for Stream Gatherers and
thought I'd mention it (apologies if you've seen these ideas already).
These might even be worth considering including as standard offerings.

Motivating example: Suppose you have a large list of people sorted by
LastName. Your goal is to print the list ordered by LastName, then by
FirstName. The list is too large to re-sort the whole thing.

Instead, you only need to "fixup" the ordering, by re-sorting just the
groups of people with the same last name.

If you happen to know that there are no more than 100 people with the exact
same last nam, then one option would be a Gatherer that re-sorts a stream,
but only up to some maximum window size (if two elements were out of order
and separated by more than the window size, then sorted output would no
longer be guaranteed).

In the above example, you would set the window size to 100 and it might
look something like this:

listOfPeople.stream()   // sorted by lastName only
  .gather(Gatherers.windowSort(100,
Comparator.comparing(Person::lastName).thenComparing(Person::firstName)));

Another (probably better) option would be a "secondary sort" Gatherer. This
would take an already sorted stream and then apply a secondary sort. It
would collect items having the same primary sort key (however many there
were), and then re-sort those groups all at once using the secondary key:

listOfPeople.stream()   // sorted by lastName only
  .gather(Gatherers.secondarySort(Comparator.comparing(Person::lastName),
Comparator.comparing(Person::firstName)));

This kind of thing is common when querying a database that doesn't have the
required composite index corresponding to a desired composite sort, e.g.,
there is an index on LastName and an index on FirstName, but no composite
index on LastName+FirstName, etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240920/3a884a4b/attachment-0001.htm>

From swen at openjdk.org  Fri Sep 20 17:56:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Sep 2024 17:56:38 GMT
Subject: Integrated: 8340232: Optimize DataInputStream::readUTF
In-Reply-To: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
References: <7fbIXivvl9mh7EASMrql8rfTUVlo2ELf376n-rIy4go=.bb2fcfc1-6a84-4649-ade0-00f8ba3190b4@github.com>
Message-ID: <6ukjpLAKCkEYFed31zbXQmt1hbIr3ijg0-fNL0vvgxk=.34cae56b-c5b0-435d-86f6-4552a9a59711@github.com>

On Sun, 8 Sep 2024 07:52:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to ObjectInputStream, use JLA.countPositives and JLA.inflateBytesToChars to speed up readUTF

This pull request has now been integrated.

Changeset: 40fba148
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40fba148125b9e0d35755b6e6fd701e69d22f7da
Stats:     42 lines in 1 file changed: 28 ins; 2 del; 12 mod

8340232: Optimize DataInputStream::readUTF

Reviewed-by: liach, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/20903

From alanb at openjdk.org  Fri Sep 20 18:00:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Sep 2024 18:00:36 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v3]
In-Reply-To: <1WCK4NwQu9fhihVBbwqw-3Up9mkxlVafoLkqE1UEUUw=.52d0ab3d-a36b-4f84-bb04-0fe4d709014f@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <1WCK4NwQu9fhihVBbwqw-3Up9mkxlVafoLkqE1UEUUw=.52d0ab3d-a36b-4f84-bb04-0fe4d709014f@github.com>
Message-ID: <7jvEOaiGcvWipOKl33jPiiTDxtyOwK2mLILEITZzTPc=.486d8f96-cbf5-4261-ae2f-f78cc442de82@github.com>

On Fri, 20 Sep 2024 15:54:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated javadoc based on last round of input

Latest updates to the API docs looks okay. I didn't do a detailed review of the test updates.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21003#pullrequestreview-2318920557

From ccheung at openjdk.org  Fri Sep 20 18:03:52 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 20 Sep 2024 18:03:52 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v2]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <LP6_eMV2JUsQ309eTWGnV1zNuatfL-_ka4j-9zhaPcY=.390fc46b-0c4c-41a1-90a4-5f0e623a85c3@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  comments from David, Alan, and Ioi

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/33c9d247..c6fc5bd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=00-01

  Stats: 138 lines in 12 files changed: 86 ins; 37 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From jjg at openjdk.org  Fri Sep 20 18:16:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 20 Sep 2024 18:16:42 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v15]
In-Reply-To: <jrUNyuO71nVf9r_jcX9Mgl-XZuSi8jiCsbo2VvDG024=.a46d6da5-e82d-4b4c-8a91-980045f88704@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <jrUNyuO71nVf9r_jcX9Mgl-XZuSi8jiCsbo2VvDG024=.a46d6da5-e82d-4b4c-8a91-980045f88704@github.com>
Message-ID: <ICsVeGdzReKQPwG7WlIXDbUF0ofMGjXNGBmAPtwYI5o=.d5e37d6a-8a7d-497c-bddb-e5984a4c54e6@github.com>

On Fri, 20 Sep 2024 14:02:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - exclude list is now module specific
>  - remove empty if statement, debugging showed the condition is never true
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/3c22d83c...62a34064

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2318971590

From ccheung at openjdk.org  Fri Sep 20 18:16:57 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 20 Sep 2024 18:16:57 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/c6fc5bd8..61ffd1b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From ccheung at openjdk.org  Fri Sep 20 18:19:42 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 20 Sep 2024 18:19:42 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <8QVb7SLhVWE1Q0U7_2oOpcltcNbKEYw4PJ1zi01U-tc=.207e30c8-4c9b-40da-a3a5-9389c4fcc44b@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <8QVb7SLhVWE1Q0U7_2oOpcltcNbKEYw4PJ1zi01U-tc=.207e30c8-4c9b-40da-a3a5-9389c4fcc44b@github.com>
Message-ID: <QkZDiBlJaD4FJTjAZDih_8Q71jF9z5k07D8pkpHS3wQ=.f29f290e-f3dc-4965-a995-51ec2ae9eeb9@github.com>

On Wed, 18 Sep 2024 01:15:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trailing whitespace
>
> src/hotspot/share/cds/filemap.cpp line 931:
> 
>> 929: bool FileMapInfo::is_jar_suffix(const char* filename) {
>> 930:   const char* dot = strrchr(filename, '.');
>> 931:   if (strcmp(dot + 1, "jar") == 0) {
> 
> What if there is no dot? We need a null check.

Added a null check.

> src/hotspot/share/cds/filemap.hpp line 558:
> 
>> 556:                     unsigned int dumptime_prefix_len,
>> 557:                     unsigned int runtime_prefix_len) NOT_CDS_RETURN_(false);
>> 558:   bool  is_jar_suffix(const char* filename);
> 
> Suggestion: has_jar_suffix

Fixed. Also moved the function to ClassLoaderExt.cpp.

> src/hotspot/share/cds/heapShared.cpp line 884:
> 
>> 882:       ClassLoaderExt::num_module_paths() > 0) {
>> 883:     log_info(cds, heap)("    is_using_optimized_module_handling %d num_module_paths %d jdk.module.main %s",
>> 884:         CDSConfig::is_using_optimized_module_handling(), ClassLoaderExt::num_module_paths(), Arguments::get_property("jdk.module.main"));
> 
> Why are you printing a bool value as an int? I'm surprised one of the format checkers doesn't complain about it.

I changed it to BOOL_TO_STR and updated the log statement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1769018271
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1769018370
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1769018601

From aturbanov at openjdk.org  Fri Sep 20 19:22:34 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 20 Sep 2024 19:22:34 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
Message-ID: <8mGbZyIlLNeH_XvfkdKmlXvV_hPC6seJpNEt8l7hL8w=.b3477d7e-e345-49b5-90ce-222054fbc520@github.com>

On Fri, 20 Sep 2024 02:53:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redo removal of `resource.wxl-file-name` property
>  - Revert "8338918: Remove non translated file name from WinResources resource bundle"
>    
>    This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.

Changes requested by aturbanov (Committer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/I18N.java line 66:

> 64:     }
> 65: 
> 66:     private final static MultiResourceBundle BUNDLE;

nit: use blessed modifiers order
Suggestion:

    private static final MultiResourceBundle BUNDLE;

-------------

PR Review: https://git.openjdk.org/jdk/pull/21100#pullrequestreview-2319125628
PR Review Comment: https://git.openjdk.org/jdk/pull/21100#discussion_r1769112932

From cjplummer at openjdk.org  Fri Sep 20 20:38:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 20 Sep 2024 20:38:35 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <BM1xZl0lrzbLYOasWiCMvDepPbvM6UvxFudV5b6NThI=.b50b0540-fd6d-4b4b-ad36-6d60310d0eda@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <tzwuAXVnDvgziQxJHpZPuxd0oCsGXIO1kb8M4vRUttg=.17d6d31d-8532-4615-9e1b-958bee18e75c@github.com>
 <BM1xZl0lrzbLYOasWiCMvDepPbvM6UvxFudV5b6NThI=.b50b0540-fd6d-4b4b-ad36-6d60310d0eda@github.com>
Message-ID: <MUbrv0RLZ-N7TXm4LqRqsU9QXpADsbe7wt5DuCA5LGQ=.591eea8a-9bd0-4791-9a85-137b3190e877@github.com>

On Tue, 17 Sep 2024 18:30:16 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> > Do we have any apps commonly run as a Windows SYSTEM account which expect to attach to other Java apps run by a different Java version? You're suggesting that will have no impact and agreed it would seem really unusual. 8-)
> 
> Good Question @kevinjwalls. We are not aware of any customers using attach api tools with Java application of different versions. In these cases, we recommend upgrading to the latest version.

It has been a goal to maintain attach compatibility between different versions of the attaching and attached to JVMs. We've fixed bugs in this area in the past. For example, there have been changes that caused old versions of attaching tools like jstack and jcmd to fail when attaching to newer JVMs. We've gone back and fixed these issues in the past. Note in these cases the issue had to do with the protocol used to communicate arguments, not the actual attach itself. I think in the case of this PR we are talking about a failure locate/identify the target JVM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2364580522

From rriggs at openjdk.org  Fri Sep 20 20:38:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Sep 2024 20:38:43 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v3]
In-Reply-To: <KO3_0ziw1FT2vVj8QFVspqhERNcaLaDNSQeK6CsnKRs=.5a10b6b8-1205-4737-bfcf-f49375b6c581@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <KO3_0ziw1FT2vVj8QFVspqhERNcaLaDNSQeK6CsnKRs=.5a10b6b8-1205-4737-bfcf-f49375b6c581@github.com>
Message-ID: <imjDTlFYK4yJLw-jJw7mH8G1Qg0rbUL-COPiiaY6Xsg=.73b7a6a4-2efa-46d2-8f74-6b5924b64424@github.com>

On Thu, 29 Aug 2024 14:33:08 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

src/java.base/share/classes/java/io/ObjectStreamDefaultSupport.java line 39:

> 37:  *
> 38:  */
> 39: final class ObjectStreamDefaultSupport {

The class and method names are getting a bit unwieldy including "DefaultSupport".
How about "reflection" instead of "DefaultSupport";
i.e.  ObjectStreamReflection.java?

src/java.base/share/classes/java/io/ObjectStreamDefaultSupport.java line 55:

> 53:             throw new NoSuchMethodError(e.getMessage());
> 54:         } catch (IllegalAccessException e) {
> 55:             throw new IllegalAccessError(e.getMessage());

InternalError might be more obviously a "can't happen" case.

src/java.base/share/classes/java/io/ObjectStreamDefaultSupport.java line 59:

> 57:     }
> 58: 
> 59:     private static void defaultReadObject(ObjectStreamClass streamClass, Object obj, ObjectInputStream ois) throws IOException, ClassNotFoundException {

For future maintainers, it would be helpful to describe what's going here.
In particular, note that `ObjectInputStream.readFields` may have been overridden by a subclass of OIS to provide a set of field values from a different source or stream encoding.
As well as a description of pulling the field values out of the alternate GetFields and stuffing them into arrays that are then used to set the fields of the object.

src/java.base/share/classes/java/io/ObjectStreamDefaultSupport.java line 78:

> 76:                 default -> throw new IllegalStateException();
> 77:             }
> 78:         }

Before setting any of the object fields check types of objects.
`streamClass.checkObjFieldValueTypes(obj, objs)`
It avoids partially initialized objects.

src/java.base/share/classes/java/io/ObjectStreamDefaultSupport.java line 83:

> 81:     }
> 82: 
> 83:     private static void defaultWriteObject(ObjectStreamClass streamClass, Object obj, ObjectOutputStream oos) throws IOException {

Ditto here, describing a subclasses OOS can override putFields() to return a PutField instance that extracts the field values from the object and copies them into the PutField instance making the value available to be put into the stream in a custom format.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 470:

> 468:                 return null;
> 469:             }
> 470:             field.setAccessible(true);

setAccessible() might need a doPriv to be successful in all cases.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 491:

> 489:             return 0;
> 490:         }
> 491:     }

How is this different than `ObjectStreamClass.lookup(clazz).getSerialVersionUID()` ?

And BTW, this misses the computation of the default SVUID and the SVUID of Records.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 505:

> 503:     );
> 504: 
> 505:     private static boolean isValidSerializable(Class<?> cl) {

"Valid" is too broad to clearly identify the purpose. 
You might flip it to return true for all classes that use the default serialized object format.

You might find that using the pattern language feature and "instanceof" would be effective and not need the small set.

test/jdk/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java line 379:

> 377:         @SuppressWarnings("removal")
> 378:         ObjectOutputStream oos = AccessController.doPrivileged((PrivilegedExceptionAction<ObjectOutputStream>) () -> new ObjectOutputStream() {
> 379:             protected void writeObjectOverride(final Object obj) throws IOException {

The alternate invocation of the replacement defaultWriteObject should be hooked in here, to see how the whole mechanism works smoothly. Especially for nested serializations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769226371
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1767069044
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769194000
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1767593821
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769197407
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769217751
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1679849130
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1679899170
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1714206229

From almatvee at openjdk.org  Fri Sep 20 21:49:35 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 20 Sep 2024 21:49:35 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
Message-ID: <zTmFS6P1n5OJukT9nNhCU1gbXAIepfPB50sz3WIK-Bo=.8fe7870f-0d62-47c6-8cf3-75dedc452b95@github.com>

On Fri, 20 Sep 2024 02:53:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redo removal of `resource.wxl-file-name` property
>  - Revert "8338918: Remove non translated file name from WinResources resource bundle"
>    
>    This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21100#pullrequestreview-2319405950

From duke at openjdk.org  Fri Sep 20 22:01:23 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 20 Sep 2024 22:01:23 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v4]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <WGDHTMUur7b-GAJdSpstgSs-QwRGXGB1RwpHSP0JCS0=.41402e2d-9e9b-49a2-a181-37a40be97458@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/2a734c5e..bf658a39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=02-03

  Stats: 352 lines in 4 files changed: 173 ins; 167 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From duke at openjdk.org  Fri Sep 20 22:01:23 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 20 Sep 2024 22:01:23 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v3]
In-Reply-To: <imjDTlFYK4yJLw-jJw7mH8G1Qg0rbUL-COPiiaY6Xsg=.73b7a6a4-2efa-46d2-8f74-6b5924b64424@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <KO3_0ziw1FT2vVj8QFVspqhERNcaLaDNSQeK6CsnKRs=.5a10b6b8-1205-4737-bfcf-f49375b6c581@github.com>
 <imjDTlFYK4yJLw-jJw7mH8G1Qg0rbUL-COPiiaY6Xsg=.73b7a6a4-2efa-46d2-8f74-6b5924b64424@github.com>
Message-ID: <n8DKU4NT4CNVxsL986bLORHtvrdUPkSYDyx8Yw8H4wM=.86f28290-c048-4fa1-b33c-fa338fda32e2@github.com>

On Fri, 20 Sep 2024 20:27:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 470:
> 
>> 468:                 return null;
>> 469:             }
>> 470:             field.setAccessible(true);
> 
> setAccessible() might need a doPriv to be successful in all cases.

Other methods on this class do not use `doPrivileged()` so I thought it would be best to copy them; this, custom serialization libraries are using their own `doPrivileged()` blocks for those methods already. This could probably be safely changed (since a runtime permission is already required to access the user-facing `ReflectionFactory` class anyway), but would it be best to change it all at once? Or would it be better to leave it as is?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769270696

From duke at openjdk.org  Fri Sep 20 22:01:24 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 20 Sep 2024 22:01:24 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v4]
In-Reply-To: <imjDTlFYK4yJLw-jJw7mH8G1Qg0rbUL-COPiiaY6Xsg=.73b7a6a4-2efa-46d2-8f74-6b5924b64424@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <KO3_0ziw1FT2vVj8QFVspqhERNcaLaDNSQeK6CsnKRs=.5a10b6b8-1205-4737-bfcf-f49375b6c581@github.com>
 <imjDTlFYK4yJLw-jJw7mH8G1Qg0rbUL-COPiiaY6Xsg=.73b7a6a4-2efa-46d2-8f74-6b5924b64424@github.com>
Message-ID: <4BgvzADGAwvlz3NXZSb2nHUu37JDBxgeiF_wvoCHVtA=.4703437c-2a86-4617-82c6-4c49159188a6@github.com>

On Tue, 16 Jul 2024 18:17:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedback
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 491:
> 
>> 489:             return 0;
>> 490:         }
>> 491:     }
> 
> How is this different than `ObjectStreamClass.lookup(clazz).getSerialVersionUID()` ?
> 
> And BTW, this misses the computation of the default SVUID and the SVUID of Records.

The `ObjectStreamClass` computes a default value if there is no field, so serialization frameworks do not have any way to know whether a default value or explicitly specified value is in use. That said - I'm looking over the custom serializer code that we have and I think we switched to using `ObjectStreamClass` a while ago so I can just remove this whole method.

> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 505:
> 
>> 503:     );
>> 504: 
>> 505:     private static boolean isValidSerializable(Class<?> cl) {
> 
> "Valid" is too broad to clearly identify the purpose. 
> You might flip it to return true for all classes that use the default serialized object format.
> 
> You might find that using the pattern language feature and "instanceof" would be effective and not need the small set.

Sure, I can rename this and invert it.

I haven't used the pattern feature much so far, but after reading JEP 441 again and looking for other examples, while I see how an object can be matched with `instanceof`, I can't figure out a way to use it to switch on an actual `Class` object in this way. Am I missing something?

> test/jdk/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java line 379:
> 
>> 377:         @SuppressWarnings("removal")
>> 378:         ObjectOutputStream oos = AccessController.doPrivileged((PrivilegedExceptionAction<ObjectOutputStream>) () -> new ObjectOutputStream() {
>> 379:             protected void writeObjectOverride(final Object obj) throws IOException {
> 
> The alternate invocation of the replacement defaultWriteObject should be hooked in here, to see how the whole mechanism works smoothly. Especially for nested serializations.

So far I'm unit testing each method to show that it works to its own specification; in order to fully integrate with multiple classes and nested objects, it seems as though I'd have to implement an entire custom serialization framework for the test, which does not seem feasible; the generated method does not relate in any way to nested serializations (that would be solely the job of the framework which uses it).

The only difference I can see between directly using the generated `default(Read|Write)Object` and one which uses them indirectly by way of a `Ser#(read|write)Object()` calling through `Object*Stream.default(Read|Write)Object()` is the call path through the test classes and mocks. But, I could possibly add a couple more tests with another pair of slightly different mocked streams which "tracks" the "current" object (of which there would just be one) and makes sure that `default(Read|Write)Object` also calls through the handle, just to show that it works, though I don't think this adds any surety or even code coverage to the overall tests since all of the additional code would exist only in the unit test (i.e. I'd be writing a test that proves that the test works, not that the feature works).

I do believe that this feature is fully covered by the existing tests, but if I am missing some subtle detail we can discuss further of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769274124
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769278913
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1769300945

From asemenyuk at openjdk.org  Fri Sep 20 22:45:57 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Sep 2024 22:45:57 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v3]
In-Reply-To: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
Message-ID: <OhSgZj-mWHfu2mkqST4xSBLsjBxF4TrsR8_eXAQo1VA=.e717baca-cbc4-41e6-be67-253866755444@github.com>

> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix order of modifiers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21100/files
  - new: https://git.openjdk.org/jdk/pull/21100/files/9562086c..a7b378a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21100&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21100&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21100/head:pull/21100

PR: https://git.openjdk.org/jdk/pull/21100

From jlu at openjdk.org  Fri Sep 20 22:45:57 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Sep 2024 22:45:57 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v3]
In-Reply-To: <OhSgZj-mWHfu2mkqST4xSBLsjBxF4TrsR8_eXAQo1VA=.e717baca-cbc4-41e6-be67-253866755444@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <OhSgZj-mWHfu2mkqST4xSBLsjBxF4TrsR8_eXAQo1VA=.e717baca-cbc4-41e6-be67-253866755444@github.com>
Message-ID: <XjW2TSty-2AdO05vMG988x5G1xpo4V0mBoC5fLZKlvY=.a72d251f-9980-45cf-8da6-f7276a734685@github.com>

On Fri, 20 Sep 2024 22:42:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix order of modifiers

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21100#pullrequestreview-2319481417

From asemenyuk at openjdk.org  Fri Sep 20 22:45:57 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Sep 2024 22:45:57 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <8mGbZyIlLNeH_XvfkdKmlXvV_hPC6seJpNEt8l7hL8w=.b3477d7e-e345-49b5-90ce-222054fbc520@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
 <8mGbZyIlLNeH_XvfkdKmlXvV_hPC6seJpNEt8l7hL8w=.b3477d7e-e345-49b5-90ce-222054fbc520@github.com>
Message-ID: <MXiYLKa3EfBXpr1dAWrEDXPNI0KGm5-ukVr_zFv_P4s=.464f696c-4f5a-47e2-b88b-7a487e2ffcbd@github.com>

On Fri, 20 Sep 2024 19:19:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Redo removal of `resource.wxl-file-name` property
>>  - Revert "8338918: Remove non translated file name from WinResources resource bundle"
>>    
>>    This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/I18N.java line 66:
> 
>> 64:     }
>> 65: 
>> 66:     private final static MultiResourceBundle BUNDLE;
> 
> nit: use blessed modifiers order
> Suggestion:
> 
>     private static final MultiResourceBundle BUNDLE;

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21100#discussion_r1769332407

From redestad at openjdk.org  Fri Sep 20 23:57:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Sep 2024 23:57:36 GMT
Subject: RFR: 8340544: Optimize setLocalsFromArg [v2]
In-Reply-To: <ACnTTe6Oqx87t93koDr1pgKl4sSDpITuNM-y9KFkHY8=.65614756-328f-4332-85d2-f3096139be34@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
 <ACnTTe6Oqx87t93koDr1pgKl4sSDpITuNM-y9KFkHY8=.65614756-328f-4332-85d2-f3096139be34@github.com>
Message-ID: <H9XPT4rupOvHwtjV7OjRinfzkYgsHqH996CEnG1snE0=.2eff448f-d78b-4033-be7d-7e881342af47@github.com>

On Fri, 20 Sep 2024 16:35:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more compact

LGTM

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1070:

> 1068:                 } else {
> 1069:                     if (desc instanceof ReferenceClassDescImpl) {
> 1070:                         type = Type.referenceType(desc);

Not for this PR, but `Type.referenceType(ClassDesc desc)` is always just creating a new `Type` - perhaps it would be profitable to do some quick checks such as `if (desc == CD_Object) return TYPE_OBJECT;` in that method?

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21106#pullrequestreview-2319515225
PR Review Comment: https://git.openjdk.org/jdk/pull/21106#discussion_r1769360053

From swen at openjdk.org  Sat Sep 21 00:23:40 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 21 Sep 2024 00:23:40 GMT
Subject: Integrated: 8339217: Optimize ClassFile API loadConstant
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <vSQ5Qwnca2PmcMilNhI7Rv_7rdp4kN6nBoWK1u9Xbv4=.8c97ffba-763f-4af0-81f7-0ad469dd05ea@github.com>

On Thu, 29 Aug 2024 05:01:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

This pull request has now been integrated.

Changeset: 2461263a
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2461263aac35b25e2a48b6fc84da49e4b553dbc3
Stats:     90 lines in 2 files changed: 63 ins; 22 del; 5 mod

8339217: Optimize ClassFile API loadConstant

Reviewed-by: liach, redestad, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20761

From swen at openjdk.org  Sat Sep 21 00:39:47 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 21 Sep 2024 00:39:47 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v2]
In-Reply-To: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
Message-ID: <VPL9VbC9YOyV9-kvEihi_V6CVHSFCVxLIKHIHPu_rhI=.4a1132e1-7760-4dad-b072-f771300cd07e@github.com>

> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - optimize Utf8EntryImpl inflate
 - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - Suggestions from @liach
 - fix build error
 - optimize Utf8EntryImpl inflate

-------------

Changes: https://git.openjdk.org/jdk/pull/20767/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20767&range=01
  Stats: 76 lines in 1 file changed: 23 ins; 20 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/20767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20767/head:pull/20767

PR: https://git.openjdk.org/jdk/pull/20767

From duke at openjdk.org  Sat Sep 21 00:40:49 2024
From: duke at openjdk.org (duke)
Date: Sat, 21 Sep 2024 00:40:49 GMT
Subject: Withdrawn: 8313205: Modernize java.text.Format with StringBuilder
In-Reply-To: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
References: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
Message-ID: <8VyvrgyfSy3B34mVSuTH-rCvLZodCaq0IHuoTn0FCqU=.fc02a290-3d43-4780-b4b0-f7e36fd7227c@github.com>

On Thu, 25 Jul 2024 22:18:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses.
> 
> While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it.
> 
> The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods.
> 
> A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20337

From davidalayachew at gmail.com  Sat Sep 21 04:18:59 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 21 Sep 2024 00:18:59 -0400
Subject: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <CAL5bRt-icdkgyK2RqG36HbOGhP_+2FsGLwP+9KMkdd4X5WZPqg@mail.gmail.com>
References: <20240902175543.44781778E42@eggemoggin.niobe.net>
 <CAA9v-_NuxJZ1gT7X-adH=xsG_u3RjVfeO4YwxEbBBtW=dHpFtQ@mail.gmail.com>
 <CAL5bRt-icdkgyK2RqG36HbOGhP_+2FsGLwP+9KMkdd4X5WZPqg@mail.gmail.com>
Message-ID: <CAA9v-_ObweMD8FZxBH_5C6vUJj2ZN6QxSAAjH82HeBMnb8vzsQ@mail.gmail.com>

Nope. Just bring up your experiences with the feature, and if it's valuable
enough, they will add it.

One good example is Stream::multiMap. Stream came out in Java 8, but that
feature came out in Java 16. So, the best thing to focus on is just
reporting your experiences as they occur.

On Wed, Sep 18, 2024, 8:12?AM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> Is in-built gatherers list finalized? I was thinking that
> Gatherers::uniqueBy(Function<OUT, DISCRIMINATOR>) could be very popular
> among stream users, although it is fairly easy to implement yourself (as
> well as bunch of currently in-built ones though)
>
> On Tue, Sep 3, 2024, 00:59 David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Thanks. Glad to see this finally land. That slidingWindow and other
>> related functions are extremely powerful.
>>
>> On Mon, Sep 2, 2024 at 3:13?PM Mark Reinhold <mark.reinhold at oracle.com>
>> wrote:
>>
>>> https://openjdk.org/jeps/485
>>>
>>>   Summary: Enhance the Stream API to support custom intermediate
>>>   operations.  This will allow stream pipelines to transform data in ways
>>>   that are not easily achievable with the existing built-in intermediate
>>>   operations.
>>>
>>> - Mark
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240921/8d429ab4/attachment.htm>

From liach at openjdk.org  Sat Sep 21 04:23:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 21 Sep 2024 04:23:41 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v6]
In-Reply-To: <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <nYHB5fkz9GEytzZFnumhjqd0y6HGiDmGtdXEP_6RJyU=.c817eb9d-c304-461d-beb4-aed8adbe6ee8@github.com>
Message-ID: <9dkKHKZ-URofKhJ8mM65Jm-w51h0DuTdK1s5bovCgvo=.90c898b0-04a1-44d3-857d-a4d4a901b08b@github.com>

On Sat, 14 Sep 2024 02:45:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

The CSR asks to use `equivalent` instead of `identical` in the specs; I should fix that in a subsequent general ClassFile API docs cleanup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20761#issuecomment-2364992208

From alanb at openjdk.org  Sat Sep 21 06:33:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Sep 2024 06:33:37 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
Message-ID: <7x-dr_M70dbSsP6Jr-QIY1g40vSdKMnXmkwfuUElzDg=.ca786a00-1613-4db3-a53b-0ce01942e5bd@github.com>

On Fri, 20 Sep 2024 18:16:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

src/java.base/share/classes/jdk/internal/module/ModuleReferences.java line 105:

> 103:             public byte[] generate(String algorithm) {
> 104:               return ModuleHashes.computeHash(supplier, algorithm);
> 105:             }

Why is JarModuleReader changed to use a file string, is this because of an environment dependency when using a Path?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1769487689

From duke at openjdk.org  Sat Sep 21 06:44:44 2024
From: duke at openjdk.org (duke)
Date: Sat, 21 Sep 2024 06:44:44 GMT
Subject: Withdrawn: 8333893: Optimization for StringBuilder append boolean &
 null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <35kiZDoVYk78VZHgNIqXfyWigKKTDqX4jn4ZH3GHCLo=.1367ac27-6bdf-43f0-9550-a4357fbd84e3@github.com>

On Mon, 10 Jun 2024 12:12:58 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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19626

From lancea at openjdk.org  Sat Sep 21 14:51:17 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 21 Sep 2024 14:51:17 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v4]
In-Reply-To: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
Message-ID: <KxRv_HAv_gnNGcccDIb5WKdNnji7rg2QGk7isujQ1TU=.f5b0971d-e7b4-4eae-a4ba-aaba01c2fefa@github.com>

> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
> 
> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
> 
> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Minor wordsmithing as part of the finalization of the CSR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21003/files
  - new: https://git.openjdk.org/jdk/pull/21003/files/69cf3312..e250340b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21003/head:pull/21003

PR: https://git.openjdk.org/jdk/pull/21003

From alanb at openjdk.org  Sat Sep 21 15:03:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Sep 2024 15:03:40 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
Message-ID: <KUKq2zJNpjjIK_JFCBwXKSeq8wrx0vhjF7WRevd_ePU=.591d3058-2569-473b-91e7-97a3fce9aab4@github.com>

On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: "  Doing" -> " Doing" and add some {@code} tags

src/java.base/share/classes/java/io/BufferedInputStream.java line 58:

> 56:  * incorrect result since each instance of {@code BufferedInputStream}
> 57:  * maintains its own state.
> 58:  *

It might be clearer to just say that once wrapped with a BIS, the underlying input stream should not be used directly or wrapped with another stream. This is potentially something for an apiNote as it's more about API usage,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1769589981

From alanb at openjdk.org  Sat Sep 21 15:07:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Sep 2024 15:07:35 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
Message-ID: <EaOMJqCjedsGIFA6akKUACFnaQs4k2u6XstmC5tIgTs=.407460a7-3d44-4558-9208-3f958fe2f3f5@github.com>

On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: "  Doing" -> " Doing" and add some {@code} tags

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20320#pullrequestreview-2319824258

From rafael.wth at gmail.com  Sat Sep 21 21:14:40 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sat, 21 Sep 2024 23:14:40 +0200
Subject: ClassLoader API to look up class files
Message-ID: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>

Hello,
It is a quite common need for Java agents to resolve class files for Java
classes by their name. Normally, this is done by requesting a resource from
the class loader. So if a class:

pkg.SampleClass

is requested, the agent calls
ClassLoader.getResourceAsStream("pkg/SampleClass.class"). This normally
works well, with a few exceptions where class loaders do not implement
lookup.

However, with multi-release jars this is less reliable. In theory, on a
Java 23 VM I would need to request all from:

"META-INF/versions/23/pkg/SampleClass.class"
to
"META-INF/versions/9/pkg/SampleClass.class"
and finally
"pkg/SampleClass.class"

This is of course not scalable. To ease the process, I wanted to suggest to
add a method to class loader:

public InputStream getClassFileAsStream(String name, short version) {
  return getResourceAsString(name.replace('.', '/') + ".class");
}

In the default implementation, this would simply fall back to finding the
resource in the standard location. However, class loaders could override
this method to look up the class file for a class from different locations.
Normally, the class loader has better knowledge of the represented class
files and can look up multi-release files more efficiently than by
iterating over a growing number of locations.

Is this something that could be considered?

Thanks! Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240921/64129fae/attachment.htm>

From swen at openjdk.org  Sun Sep 22 01:04:52 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 22 Sep 2024 01:04:52 GMT
Subject: Integrated: 8340544: Optimize setLocalsFromArg
In-Reply-To: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
References: <tMhqCm-1B19AXv-Vk0LdHgsfmclCtiEBSAKzckCXBVw=.98ce2d10-9816-4aca-a0b6-51d9a51e146d@github.com>
Message-ID: <AfwgqQD7YqOOBUk12YgxT6dmIdXH92G05TqYmRI2QWQ=.0308d8f1-20f9-44c7-b45f-ff262726f5aa@github.com>

On Fri, 20 Sep 2024 09:18:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method size, codeSize is reduced from 367 to 263.

This pull request has now been integrated.

Changeset: ab06a878
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab06a878f888827026424530781f0af414a8a611
Stats:     27 lines in 1 file changed: 8 ins; 5 del; 14 mod

8340544: Optimize setLocalsFromArg

Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/21106

From liach at openjdk.org  Sun Sep 22 02:06:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 22 Sep 2024 02:06:44 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v17]
In-Reply-To: <uLIeI8246MZSqmJ4_IR3Zq5PDV0DAo-DiELcHHmeUg0=.8ffc43d7-4de4-40b9-8bc9-f80891d5732e@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uLIeI8246MZSqmJ4_IR3Zq5PDV0DAo-DiELcHHmeUg0=.8ffc43d7-4de4-40b9-8bc9-f80891d5732e@github.com>
Message-ID: <YbjSo7k8-LgOJOtF4KzE2GBvY1y52OIjU4-76-LJmSE=.93a6ca6f-da8e-40be-95ca-7bda0bad8c30@github.com>

On Sat, 24 Aug 2024 06:27:26 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 19 additional commits since the last revision:
> 
>  - 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 'upstream/master' into optim_str_builder_append_202406
>  - replace unsafe with putChar
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - private static final field `UNSAFE`
>  - Utf16 case remove `append first utf16 char`
>  - `delete` -> `setLength`
>  - copyright 2024
>  - optimization for x64
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/381c1987...61196ecd

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 640:

> 638:     private AbstractStringBuilder appendNull() {
> 639:         ensureCapacityInternal(count + 4);
> 640:         int count = this.count;

We should declare `count` before `ensureCapacitiyInternal`. Same for append boolean.

test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java line 136:

> 134: 
> 135:     public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
> 136:         return StringUTF16.putCharsAt(value, i, c1, c2, c3, c4);

Why do we remove the tests for UTF16? And should we add another set of test for LATIN1 too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1769695101
PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1769694934

From alan.bateman at oracle.com  Sun Sep 22 07:46:38 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 22 Sep 2024 08:46:38 +0100
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
Message-ID: <bced02cc-5151-42e5-80c9-dc48ed69f60d@oracle.com>

On 21/09/2024 22:14, Rafael Winterhalter wrote:
> Hello,
> It is a quite common need for Java agents to resolve class files for 
> Java classes by their name. Normally, this is done by requesting a 
> resource from the class loader.

I agree that the scalability issue with MR JARs deserves attention. JEP 
238 pre-dates the 6 month cadence where we now add two additional 
versions to search each year. I don't think this issue is really 
anything to do with Java agents or the ClassLoader API, instead this is 
about the JarFile implementation. Some experiments needed but it may be 
more efficient to find and cache the names of the entries that are 
versioned, and avoid looping through the versions altogether.

-Alan








From jbhateja at openjdk.org  Sun Sep 22 09:49:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 22 Sep 2024 09:49:38 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <o8wCa0e5Lfl7WZeUorer5E_KFp2ZuM-n6alXFwBIZxE=.c491c809-5085-46f1-aef3-cdb2554bde11@github.com>

On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

> Got it, I think #20508 and this PR are unrelated implementation-wise, though.
> 
> @jatin-bhateja What do you think of using this patch and intrinsifing `Vector<E>::rearrange(VectorShuffle<E>, Vector<E>)` instead of introducing the 2 vector `selectFrom` API?

Hi @merykitty , I had implemented as [similar LoadShuffle bypassing optimization](https://github.com/openjdk/jdk/pull/20508/commits/7c80bfce59f486f6c25aec13f0f0f6a42f5319b1) in my original implementation of PR #20508  , which we decided to address in subsequent patch for both the flavors of selectFromAPI.

Main difference b/w two vector re-arrange and selectFrom API is w.r.t to their signatures and acceptable index ranges post wrapping. In the latter case wrapping brings down the index range into [0, 2*VLEN -1) while in the former case we prune the exceptional indexes into valid single vector index range [0, VLEN) augmented with selection mask which picks the elements from independently permuted vectors to produce result vector.

Unlike single vector re-arrange which now favors index wrapping parting ways from throwing IndexOutOfBounds exception for exceptional indexes (-ve indexes),  two vector re-arrange wraps exceptional indexes into valid single vector range. To bring the exceptional indexes into valid two vector range will need changes int wrapping logic to add 2*VECLEN to exceptional indexes, but this may be implemented in target specific manner, we can take this up in a follow up patch after integrating #20508

As Paul mentioned, vector rearrange and selectFrom are complimentary APIs with different signatures and we intend to produce optimal code for both.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2366421736

From jpai at openjdk.org  Sun Sep 22 12:50:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 22 Sep 2024 12:50:34 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <mwyaxktWjoPoB5klx6cturILOndu_0usfw_HM0VbOuo=.8625d290-acc4-468d-83c9-68f7da1ba06b@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

Hello Matthias, please give me a day or so to run this against our internal CI to make sure there are no unexpected issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21082#issuecomment-2366771835

From alanb at openjdk.org  Sun Sep 22 14:57:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 22 Sep 2024 14:57:35 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v7]
In-Reply-To: <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
Message-ID: <TRvT--7HxmOtvHZQad5PJgK9Lb6AIQ_xXP0ebbK5ZI8=.7081e73c-3346-4a4b-a766-9dd50249d2d4@github.com>

On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treat -version: -jre-restrict-search and -jre-no-restrict-search like any other unknown option

src/java.base/share/native/libjli/java.h line 58:

> 56:  * java runtime (older, newer or same version JRE installed at a different location) than
> 57:  * the one the launcher belongs to.
> 58:  * That support was discontinued starting Java 9. However, java launcher in JDK 1.8 can still

I assume this should say "Java 9" rather than "JDK 9".

I read this paragraph a few times and one thing that I don't think is made clear is that it's the JDK 8 launcher that is exec'ing the JDK N launcher with the env variable set. Instead it speaks of launching the "higher version java runtimes". At some point we are going to have to fix an exit route. In the mean-time, anyone touching this code will read this and it may not be clear how the JDK N launcher gets exec'ed with this env variable set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770572582

From alanb at openjdk.org  Sun Sep 22 15:02:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 22 Sep 2024 15:02:35 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v7]
In-Reply-To: <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
Message-ID: <GCp9gNTM9xul6GvcQergh7Y5H9MpoaJeVT7rOQdips4=.19b05d45-dade-422c-b297-9a09651dba2d@github.com>

On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treat -version: -jre-restrict-search and -jre-no-restrict-search like any other unknown option

src/java.base/share/native/libjli/java.c line 1401:

> 1399: SetupSplashScreenEnvVars(const char *splash_file_path, // "-splash:" option value (may be NULL)
> 1400:                          char *jar_path // the jar file being launched (may be NULL)
> 1401: ) {

I think this would be a bit cleaner if you put comment on the function to document the two args. That would remove the // comments that make this hard to read right now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770573678

From alanb at openjdk.org  Sun Sep 22 15:36:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 22 Sep 2024 15:36:36 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <WhG8jlLAttk0bO_beHeYTh7G3lhWR-uRvJdPqVr_wj4=.2a8b5a00-5382-46df-8e39-abcfa76fc64b@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
 <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com>
 <WhG8jlLAttk0bO_beHeYTh7G3lhWR-uRvJdPqVr_wj4=.2a8b5a00-5382-46df-8e39-abcfa76fc64b@github.com>
Message-ID: <XQQv6Ry03Tw27yo_CGmJyIcIR1U2UgbQXwqhwOv_qrY=.0e41f9dd-c158-473e-8493-25435b8b43c4@github.com>

On Fri, 6 Sep 2024 13:16:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Looks good. I'll review the CSR when its ready.
>
>> Looks good. I'll review the CSR when its ready.
> 
> Thanks.
> 
>> The changes to make jdk.jsobject an upgradeable module looks right.
> 
> Thanks for checking. My testing primarily focused on this aspect of the change, so it's pretty well tested.
> 
>> I was initially surprised by the wording "will be delivered with JavaFX" but after playing with a few alternatives I concluded that what we have is okay.
> 
> Yeah, I tried a few variants and couldn't come up with anything better.

@kevinrushforth Is the CSR on your list to write?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2366841622

From alanb at openjdk.org  Sun Sep 22 15:40:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 22 Sep 2024 15:40:40 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <lpAJFQgaXlTZuYwlyIcSqkyt_6GrsqnhNSuA_qIloPo=.2a72e137-04c6-4100-9471-ebab14c0bbb8@github.com>

On Mon, 16 Sep 2024 17:50:52 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> ?nge while creating a jlink image

It would be helpful for potential reviewers if the PR description included a brief summary on the changes to the code generated, otherwise it's a lot to wade through to understand the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21022#issuecomment-2366842885

From eirbjo at gmail.com  Sun Sep 22 15:42:01 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 22 Sep 2024 17:42:01 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <bced02cc-5151-42e5-80c9-dc48ed69f60d@oracle.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <bced02cc-5151-42e5-80c9-dc48ed69f60d@oracle.com>
Message-ID: <CA+pBWhvu478Co3SXO-Vuwn=7nav3BrGt_kViH+DG0oLT3uo3zA@mail.gmail.com>

On Sun, Sep 22, 2024 at 12:14?PM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 21/09/2024 22:14, Rafael Winterhalter wrote:
> > Hello,
> > It is a quite common need for Java agents to resolve class files for
> > Java classes by their name. Normally, this is done by requesting a
> > resource from the class loader.
>
> I agree that the scalability issue with MR JARs deserves attention. JEP
> 238 pre-dates the 6 month cadence where we now add two additional
> versions to search each year.


Alan,

JarFile.getVersionedEntry no longer searches the full historical version
range, but only tries the specific versions actually present in the JAR
file. So this probably isn't as bad as it sounds, assuming most
multi-release JARs only have entries for a low number of versions.

See https://bugs.openjdk.org/browse/JDK-8242596

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/29bf63f0/attachment.htm>

From eirbjo at gmail.com  Sun Sep 22 16:04:46 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 22 Sep 2024 18:04:46 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
Message-ID: <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>

On Sat, Sep 21, 2024 at 11:15?PM Rafael Winterhalter <rafael.wth at gmail.com>
wrote:

> Hello,
> It is a quite common need for Java agents to resolve class files for Java
> classes by their name. Normally, this is done by requesting a resource from
> the class loader. So if a class:
>
> pkg.SampleClass
>
> is requested, the agent calls
> ClassLoader.getResourceAsStream("pkg/SampleClass.class"). This normally
> works well, with a few exceptions where class loaders do not implement
> lookup.
>
> However, with multi-release jars this is less reliable. In theory, on a
> Java 23 VM I would need to request all from:
>

Rafael,

URLClassLoader::getResource already resolves the versioned class file
entry, that is URLClassLoader::getResource will return the URL for
"META-INF/versions/21/HelloWorld.class" when given the parameter
"HelloWorld.class" with a multi-release JAR on the class path.

So since you're re-implementing version lookup yourself, I assume what you
are experiencing here must be some third-party JAR-backed custom
classloader overriding ClassLoader.findResource without properly taking
versioned entries into account, right?

If that's the case, then the class file loaded would probably not be
versioned correctly either, right? Also, if people can't override
ClassLoader.findResource to support versioning, then I'd be surprised if
they would override a new API point like getClassFileAsStream correctly.

Perhaps you could expand a bit why you need to implement the version lookup
yourself? Which hole are you mending here?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/3fff58c2/attachment-0001.htm>

From swen at openjdk.org  Sun Sep 22 16:17:06 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 22 Sep 2024 16:17:06 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v18]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <nKrwVaWnloV8qofq9V91-lGjHxW9bIQ-jMQhfXFuE28=.4d13d8ec-cb45-4a01-b97c-9d13f9b41151@github.com>

> 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 23 additional commits since the last revision:

 - 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
 - replace unsafe with putChar
 - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
 - private static final field `UNSAFE`
 - ... and 13 more: https://git.openjdk.org/jdk/compare/7ba4356c...399c8ef5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/61196ecd..399c8ef5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=16-17

  Stats: 180711 lines in 1606 files changed: 163525 ins; 8881 del; 8305 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From swen at openjdk.org  Sun Sep 22 16:17:06 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 22 Sep 2024 16:17:06 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v18]
In-Reply-To: <YbjSo7k8-LgOJOtF4KzE2GBvY1y52OIjU4-76-LJmSE=.93a6ca6f-da8e-40be-95ca-7bda0bad8c30@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uLIeI8246MZSqmJ4_IR3Zq5PDV0DAo-DiELcHHmeUg0=.8ffc43d7-4de4-40b9-8bc9-f80891d5732e@github.com>
 <YbjSo7k8-LgOJOtF4KzE2GBvY1y52OIjU4-76-LJmSE=.93a6ca6f-da8e-40be-95ca-7bda0bad8c30@github.com>
Message-ID: <vFBaZgyxDSNCbiJbbDXAkPLwOI-cbIH_igvSegTAKVA=.6cf85d65-0c42-489c-b8b9-4982f0513e96@github.com>

On Sun, 22 Sep 2024 02:01:36 GMT, Chen Liang <liach 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 23 additional commits since the last revision:
>> 
>>  - 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
>>  - replace unsafe with putChar
>>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>>  - private static final field `UNSAFE`
>>  - ... and 13 more: https://git.openjdk.org/jdk/compare/7ba4356c...399c8ef5
>
> test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java line 136:
> 
>> 134: 
>> 135:     public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>> 136:         return StringUTF16.putCharsAt(value, i, c1, c2, c3, c4);
> 
> Why do we remove the tests for UTF16? And should we add another set of test for LATIN1 too?

An early version removed putCharsAt, so it was also removed from Helpers. I have added it back.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1770586891

From swen at openjdk.org  Sun Sep 22 16:20:40 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 22 Sep 2024 16:20:40 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v17]
In-Reply-To: <YbjSo7k8-LgOJOtF4KzE2GBvY1y52OIjU4-76-LJmSE=.93a6ca6f-da8e-40be-95ca-7bda0bad8c30@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uLIeI8246MZSqmJ4_IR3Zq5PDV0DAo-DiELcHHmeUg0=.8ffc43d7-4de4-40b9-8bc9-f80891d5732e@github.com>
 <YbjSo7k8-LgOJOtF4KzE2GBvY1y52OIjU4-76-LJmSE=.93a6ca6f-da8e-40be-95ca-7bda0bad8c30@github.com>
Message-ID: <ihUNNMVZEVVFUAk7SAxF9OxLDOM1RR-GZwsDduPYC9I=.e1a9e5d6-7d55-473a-81ff-eabdf458d971@github.com>

On Sun, 22 Sep 2024 02:03:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> We should declare `count` before `ensureCapacitiyInternal`. Same for append boolean.

Declaring count before ensureCapacityInternal will cause performance regression under x64. It took a lot of time to find this, but the underlying reason is still unclear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1770587530

From alan.bateman at oracle.com  Sun Sep 22 16:25:41 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 22 Sep 2024 17:25:41 +0100
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+pBWhvu478Co3SXO-Vuwn=7nav3BrGt_kViH+DG0oLT3uo3zA@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <bced02cc-5151-42e5-80c9-dc48ed69f60d@oracle.com>
 <CA+pBWhvu478Co3SXO-Vuwn=7nav3BrGt_kViH+DG0oLT3uo3zA@mail.gmail.com>
Message-ID: <a00f448a-4d01-41c8-ae7c-61f81e51edc2@oracle.com>



On 22/09/2024 16:42, Eirik Bj?rsn?s wrote:
> :
>
> Alan,
>
> JarFile.getVersionedEntry no longer searches the full historical 
> version range, but only tries the specific versions actually present 
> in the JAR file. So this probably isn't as bad as it sounds, assuming 
> most multi-release JARs only have entries for a low number of versions.
>
> See https://bugs.openjdk.org/browse/JDK-8242596
>
Thanks for the reminder. I remember the discussion but had forgotten 
that the change had been done. It might be enough as the number of 
versions in META-INF/versions/** should be small.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/f9134c9c/attachment-0001.htm>

From rafael.wth at gmail.com  Sun Sep 22 16:45:51 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 22 Sep 2024 18:45:51 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
Message-ID: <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>

That is only true for Class::getResource which resolves resources relative
to the loaded class's class file location. Java agents typically use
ClassLoader::getResource(AsStream) as the loaded class is not available in
the general case of transforming, and not retransforming, a class. For
example, when instrumenting a newly loaded class A in a
ClassFileTransformer, it might not be the case that its superclass B is
loaded. If class B exists in two versions as part of a multi-release jar
file, currently, you need to query the class loader of A as the JVM would
do. When loading a class, ClassLoader::findClass respects the multi-release
characteristic. But for ClassLoader::getResource, this is not the case.
This is why I want to suggest a new method where this is possible, as the
intend to resolve a class file is explicit. Currently, you need to iterate
as the ClassLoader does not expose any relevant information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/a9ede7f8/attachment.htm>

From rafael.wth at gmail.com  Sun Sep 22 17:55:10 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 22 Sep 2024 19:55:10 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <bced02cc-5151-42e5-80c9-dc48ed69f60d@oracle.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <bced02cc-5151-42e5-80c9-dc48ed69f60d@oracle.com>
Message-ID: <CA+DM0Akf-SOu=DZn4rFCXTRfwP0_LobRkw9Nd9TshuOJ3HiDTQ@mail.gmail.com>

In Byte Buddy, class files are typically looked up from a Java agent or a
build tool plugin. The underlying abstraction is a ClassFileLocator. In a
build tool, the locator is typically based on jar files or folders. Here,
the locator can determine that a jar or folder is multi-release by a
possible manifest. This is so rarely the case that it has not played a big
role in performance tests. And the file lookups are cheapish.

For an agent, however, the question is harder. An agent can only query
classes or resources from a class loader. Classes are often off limit as it
should avoid loading classes what often results in circularities. That's
why class files are loaded as resources. To make things worse, a class
loader can represent about anything, so the costs are unknown.

Therefore, even if the class loader preindexed Multi-Release versions of
classes to load, this would not automatically solve the issue for reading
class files as resources.

If the internal mechanism for multi-release jars was improved, I would
therefore hope that this fast-path access is exposed somehow via an API as
the one I suggested.

With the manual iteration over possible names on the other side, I can see
that this currently slows down the agent around 10% on a regular app,
compared to ignoring multi release jars from agents.

Thanks, Rafael

Am So., 22. Sept. 2024 um 09:46 Uhr schrieb Alan Bateman <
alan.bateman at oracle.com>:

> On 21/09/2024 22:14, Rafael Winterhalter wrote:
> > Hello,
> > It is a quite common need for Java agents to resolve class files for
> > Java classes by their name. Normally, this is done by requesting a
> > resource from the class loader.
>
> I agree that the scalability issue with MR JARs deserves attention. JEP
> 238 pre-dates the 6 month cadence where we now add two additional
> versions to search each year. I don't think this issue is really
> anything to do with Java agents or the ClassLoader API, instead this is
> about the JarFile implementation. Some experiments needed but it may be
> more efficient to find and cache the names of the entries that are
> versioned, and avoid looping through the versions altogether.
>
> -Alan
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/a3f503ae/attachment.htm>

From eirbjo at openjdk.org  Sun Sep 22 18:06:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 22 Sep 2024 18:06:37 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <z21xVtgxymCMmCB1aTAQ5f6sRe6WmXbx5-BIqK210ek=.aa4f2a88-bc06-4cf7-babe-4013331355d5@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <ewyA7EVHOTG9ZafU_iWO5JiF8nWEN6PcWdwAJ2S9F48=.563b0a55-af1e-43ca-99c6-570807925481@github.com>
 <z21xVtgxymCMmCB1aTAQ5f6sRe6WmXbx5-BIqK210ek=.aa4f2a88-bc06-4cf7-babe-4013331355d5@github.com>
Message-ID: <pEv9VouZbsktlZHounQr1nS5w_TPDENOyYPWMYnZo_o=.9fe6a8ec-6887-4d3d-825b-ae7e97cd7345@github.com>

On Mon, 16 Sep 2024 11:42:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?
>> 
>> Also, since the combined header length clause applies to "any directory record", it also applies to LOC?
>> 
>> So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?
>> 
>> Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile. 
>> 
>> Some comments inline.
>
>> I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?
>> 
>> Also, since the combined header length clause applies to "any directory record", it also applies to LOC?
>> 
>> So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?
>> 
>> Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile.
>> 
>> Some comments inline.
> 
> As this is really a corner case at best, I decided to keep the changes to a minimum and the validation in writeCEN given that is where the encoded comment bytes are obtained and written out.

@LanceAndersen 

I had a look at your update of the `CenSizeTooLarge` test.

This test uses artificially large extra fields to produce a CEN size exceeding the implementation limit. Since this otherwise would create a lot of IO and a huge file, the test writes a sparse file until the last CEN record is written, after which real bytes are written out for the "ZIP64 End of Central Directory" and "End of Central Directory" records are written.

The current extra field size of 0xFFFF is too large to pass the combined length validation introduced by this PR. Because of this, the field size is reduced to account for the CENHDR length, the length of the entry name and the length of the comment (which is added to the last entry only)

Since the comment is only added to the last entry (as a hint to SparseOutputStream),  the CEN_HEADER_SIZE no longer reflects the actual size of the CEN headers written. While the test still passes (by increasing NUM_ENTRIES as needed), this makes the test somewhat confusing for future maintainers.

Could we perhaps skip the comment altogether, and instead use equal-sized CEN records for all entries? Instead of using a comment as a signal to `SparseOutputStream` we could use a separate extra byte array on the last entry, as suggested in this diff on top of your PR:


Index: test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java b/test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java
--- a/test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java	(revision e250340ba4c8da6143f2c0032fed517d3feb8440)
+++ b/test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java	(date 1727026889012)
@@ -34,9 +34,7 @@
 import java.nio.ByteBuffer;
 import java.nio.ByteOrder;
 import java.nio.channels.FileChannel;
-import java.nio.charset.StandardCharsets;
 import java.time.LocalDateTime;
-import java.util.Arrays;
 import java.util.zip.ZipEntry;
 import java.util.zip.ZipException;
 import java.util.zip.ZipFile;
@@ -47,11 +45,6 @@
 
 public class CenSizeTooLarge {
 
-    // Helps SparseOutputStream detect write of the last CEN entry
-    private static final String LAST_CEN_COMMENT = "LastCEN";
-    private static final byte[] LAST_CEN_COMMENT_BYTES =
-            LAST_CEN_COMMENT.getBytes(StandardCharsets.UTF_8);
-
     // Entry names produced in this test are fixed-length
     public static final int NAME_LENGTH = 10;
 
@@ -71,8 +64,7 @@
      *.
      * Create a maximum extra field which does not exceed 65,535 bytes
      */
-    static final int MAX_EXTRA_FIELD_SIZE =
-            65_535 - ZipFile.CENHDR - NAME_LENGTH - LAST_CEN_COMMENT.length();
+    static final int MAX_EXTRA_FIELD_SIZE = 65_535 - ZipFile.CENHDR - NAME_LENGTH;
 
     // Data size (unsigned short)
     // Field size minus the leading header 'tag' and 'data size' fields (2 bytes each)
@@ -96,6 +88,10 @@
     // Zip file to create for testing
     private File hugeZipFile;
 
+    private static final byte[] EXTRA_BYTES = makeLargeExtraField();
+    // Helps SparseOutputStream detect write of the last CEN entry
+    private static final byte[] LAST_EXTRA_BYTES = makeLargeExtraField();
+
     /**
      * Create a zip file with a CEN size which does not fit within a Java byte array
      */
@@ -127,10 +123,6 @@
                 // Set the time/date field for faster processing
                 entry.setTimeLocal(TIME_LOCAL);
 
-                if (i == NUM_ENTRIES -1) {
-                    // Help SparseOutputStream detect the last CEN entry write
-                    entry.setComment(LAST_CEN_COMMENT);
-                }
                 // Add the entry
                 zip.putNextEntry(entry);
 
@@ -140,10 +132,11 @@
             zip.closeEntry();
 
             // Before the CEN headers are written, set the extra data on each entry
-            byte[] extra = makeLargeExtraField();
             for (ZipEntry entry : entries) {
-                entry.setExtra(extra);
+                entry.setExtra(EXTRA_BYTES);
             }
+            // Help SparseOutputSream detect the last entry
+            entries[entries.length-1].setExtra(LAST_EXTRA_BYTES);
         }
     }
 
@@ -167,7 +160,7 @@
      * Data Size  (Two byte short)
      * Data Block (Contents depend on field type)
      */
-    private byte[] makeLargeExtraField() {
+    private static byte[] makeLargeExtraField() {
         // Make a maximally sized extra field
         byte[] extra = new byte[MAX_EXTRA_FIELD_SIZE];
         // Little-endian ByteBuffer for updating the header fields
@@ -205,7 +198,7 @@
                 // but instead simply advance the position, creating a sparse file
                 channel.position(position);
                 // Check for last CEN record
-                if (Arrays.equals(LAST_CEN_COMMENT_BYTES, 0, LAST_CEN_COMMENT_BYTES.length, b, off, len)) {
+                if (b == LAST_EXTRA_BYTES) {
                     // From here on, write actual bytes
                     sparse = false;
                 }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21003#issuecomment-2366897313

From eirbjo at gmail.com  Sun Sep 22 18:40:47 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 22 Sep 2024 20:40:47 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
Message-ID: <CA+pBWhufoVcZfoKnY9eXocWf8KViDwkEZg7K-Y7nxyOktYw5-w@mail.gmail.com>

On Sun, Sep 22, 2024 at 6:46?PM Rafael Winterhalter <rafael.wth at gmail.com>
wrote:

Sorry, still not sure I understand the scenario..

That is only true for Class::getResource which resolves resources relative
> to the loaded class's class file location.
>

Class:getResource simply adds the package name prefix and calls
ClassLoader::getResource. It has no separate knowledge about the class
file's location.


> When loading a class, ClassLoader::findClass respects the multi-release
> characteristic. But for ClassLoader::getResource, this is not the case.
>

ClassLoader as such has no concept of multi-release JAR files, that's
entirely up to the class loader implementation. In OpenJDK, this is
supported by URLClassLoader, or rather URLClassPath.JarLoader::getResource,
which calls JarFile::getEntry which is where the version lookup happens.

If you have a class loader which respects multi-release characteristics in
ClassLoader::loadClass, but not in ClassLoader::getResource, then that is a
strange way to implement a class loader.

Is there some intricacy of class loader hierarchies that I'm missing here?

The following unit test demonstrates how URLClassLoader::getResource
resolves versions:

@Test
public void getVersionedClass() throws IOException {
    Path zip = Path.of("multi.zip");
    Manifest man = new Manifest();
    Attributes attrs = man.getMainAttributes();
    attrs.put(Attributes.Name.MANIFEST_VERSION, "1.0");
    attrs.put(Attributes.Name.MULTI_RELEASE, "true");
    try (JarOutputStream jo = new
JarOutputStream(Files.newOutputStream(zip), man)) {
        jo.putNextEntry(new
ZipEntry("META-INF/versions/21/com/example/HelloWorld.class"));
        jo.putNextEntry(new ZipEntry("com/example/HelloWorld.class"));
    }
    ClassLoader loader = new URLClassLoader(new URL[]
{zip.toUri().toURL()});
    URL resource = loader.getResource("com/example/HelloWorld.class");
    String path =
resource.getFile().substring(resource.getFile().indexOf("!/") + 2);
    assertEquals("META-INF/versions/21/com/example/HelloWorld.class", path);
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/182138e8/attachment.htm>

From alan.bateman at oracle.com  Sun Sep 22 18:45:05 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 22 Sep 2024 19:45:05 +0100
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
Message-ID: <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>

On 22/09/2024 17:45, Rafael Winterhalter wrote:
> That is only true for Class::getResource which resolves resources 
> relative to the loaded class's class file location. Java agents 
> typically use ClassLoader::getResource(AsStream) as the loaded class 
> is not available in the general case of transforming, and not 
> retransforming, a class. For example, when instrumenting a newly 
> loaded class A in a ClassFileTransformer, it might not be the case 
> that its superclass B is loaded. If class B exists in two versions as 
> part of a multi-release jar file, currently, you need to query the 
> class loader of A as the JVM would do. When loading a class, 
> ClassLoader::findClass respects the multi-release characteristic. But 
> for ClassLoader::getResource, this is not the case. This is why I want 
> to suggest a new method where this is possible, as the intend to 
> resolve a class file is explicit. Currently, you need to iterate as 
> the ClassLoader does not expose any relevant information.

If a URLClassLoader is created with a URL to a JAR file then it should 
open it as a MR-JAR and getResource should find the .class resources in 
the versioned section. Are you saying that this doesn't work? If it 
doesn't work then I think it would be useful to show the 
getResource(name) output. If the resource is versioned then you end with 
"!/META-INF/versions/$N/$R". But maybe this is a different type of 
ClassLoader?

-Alan


From rotanolexandr842 at gmail.com  Sun Sep 22 19:01:47 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Sun, 22 Sep 2024 22:01:47 +0300
Subject: Range API
Message-ID: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>

Hello everyone! I am writing here today to invite everyone to participate
in the discussion regarding the Range APi proposal I have made into JDK.
Here is the pull request link: https://github.com/openjdk/jdk/pull/21122,
and PR text:

This pull request describes the methods of the Range<T> interface. The
Range<T> interface represents a bounded or unbounded range. (From now on,
range, span and interval are used interchangeably, but docs only use
"range")
Goals:

   -

   *Main goal. Standardization of the Range/Interval API:* The primary
   objective of this effort is to provide a standardized interface for working
   with ranges or spans of time (or any ordered types). Many existing
   libraries offer their own custom implementations of ranges, and they differ
   in significant ways, making it harder to use and combine across different
   codebases. Standardization will ensure consistency, interoperability, and a
   more predictable interface across various contexts.
   -

   *Versatile range operations:* provide a comprehensive API for
   manipulating and querying ranges, especially those representing time
   periods or numerical intervals. The API simplifies common tasks like
   checking containment, overlaps, or adjacency between ranges.
   -

   *Support for unbounded ranges:* Unlike many existing libraries, which
   assume intervals are always bounded, this API aims to fully support
   unbounded intervals. Users will be able to define ranges with open starts
   or ends, making it suitable for temporal data that spans indefinitely in
   one direction, such as future projections or historical data with unknown
   starting points.
   -

   *Performance efficiency:* The API aims to provide optimized for
   performance implementation, that takes advantage of all possible
   simplifications and short-circuits.
   -

   *Consistency with existing libraries:* To aid adoption, the API should
   be familiar to developers who have used popular libraries like NodaTime,
   Joda-Time, Three-Ten Extra, and Boost Date_Time, but with enhancements for
   unbounded intervals, negative ranges (?), and optional return types instead
   of null values.

Non-Goals:

   -

   *Handling complex data structures beyond smple ranges:* This API is not
   intended to manage or represent complex data structures beyond ranges. For
   example, ranges that involve intricate internal states, like non-contiguous
   ranges (?) or ranges with multiple gaps, are out of scope.
   -

   *Overly simplifying range types:* While ease of use is a goal, its is
   not an aim to remove support for advanced cases like unbounded or negative
   ranges, even if this results in slightly more complex implementations. The
   API should not be skewed towards being purely a simple data structure for
   bounded ranges.
   -

   *Application-specific logic:* The API is meant to be domain-agnostic and
   general-purpose. It is not intended to allow to embed application-specific
   logic, such as calendar-based date manipulations or domain-specific
   business rules for interval comparison.
   -

   *Replacing existing libraries:* The goal is not to replace established
   libraries like Joda-Time or ThreeTen-Extra, but rather to augment these
   ideas with support for unbounded ranges and additional arithmetic
   operations. Although, it is a goal to provide interface that could
   exisiting libraries could easily retrofit into.

Motivation

The primary motivation behind standardizing the Range API is the *lack of
an established, universal interface* for handling ranges or spans across
various domains. Developers are often forced to work with different,
incompatible range implementations across libraries or to re-implement
common functionality themselves. This leads to redundant code, increased
dependencies, and greater chances for errors.

In many software systems?whether in scheduling, auditing, access control,
or financial services?ranges are used to represent periods of time,
numerical intervals, or validity spans. Without a standardized API,
developers must contend with diverse implementations that often differ in
naming conventions, behavior, and supported features. These variations
create unnecessary complexity, as developers must:

   1.

   *Introduce additional dependencies*: Many libraries provide similar
   functionality for ranges, but since they are not interchangeable,
   developers must often add extra dependencies to cover edge cases or
   specific use cases that are not available in a single library. This bloats
   the codebase and creates maintenance overhead.
   2.

   *Re-implement common logic*: In cases where no single library meets the
   required needs, developers are forced to write their own range-handling
   logic. This reinvention of basic operations such as intersection, union, or
   containment leads to redundancy, increased likelihood of bugs, and
   inconsistency in how ranges are handled across different parts of the code.
   3.

   *Fragmentation across domains*: Different libraries often define their
   own range concepts (e.g., for date-times, numbers, or general comparisons),
   which are rarely compatible with one another. This lack of compatibility
   makes integration between systems difficult, requiring custom adapters or
   conversions.

By defining a standard Range API, the goal is to:

   - *Reduce the dependency footprint:* A common, well-designed API for
   ranges would eliminate the need to import multiple libraries just to handle
   different types of ranges, reducing dependencies in projects and enhancing
   maintainability.
   - *Simplify code and increase reusability:* With a standardized
   interface, developers can write range-related code once and reuse it across
   projects and libraries, confident that the same semantics and operations
   will apply consistently.
   - *Minimize developer errors:* By providing a predictable and
   well-documented interface, the likelihood of misunderstandings or incorrect
   use of range operations will decrease. Developers can trust that operations
   like intersections, unions, and comparisons will behave consistently,
   regardless of the context.

In essence, the lack of standardization in range operations creates
unnecessary complexity, fragmentation, and redundant effort. A standardized
Range API would provide clarity, reduce the need for additional
dependencies, and enable more efficient, reusable, and error-free code
across different projects and domains.
Key API pointsSupport of unbounded intervals

API supports both one- and two-sided. Provided sample (draft)
implementation for ChronoDateTime has 4 separate implementation for each
type of ranges.
Alternatives

   - Many Libraries, like Luxon, C++ boost, NodaTime and many others,
   arguably the most, fo not explicitly support unbounded intervals. This
   reduces complexity of implementation, but takes away many possible
   optimization for edge-cases. Alternative they propose is to use Instant.MIN
   and Instant.MAX or similar to create unbounded-like intervals.

Support for negative intervals,

API supports both positive and negative and positive ranges. This is
questionable and discussion is encouraged.
Advantages

   - Allows more flexible usage of API, which would be helpful for use
   cases like diagrams visualization.

Disadvantages

   - Dramatically increases amount of boilerplate code inside the
   implementations.
   - Makes behaviour of potential methods like boolean endsBefore(T t)
unintuitive.
   Does this mean that end() is before that provided parameter, or latter of
   bounds (i.e. start() for negative range and end() for positive).
   - Limited usability scope. Most use cases would not benefit from
   possibility of negative ranges creation, but would have to suffer
   performance decrease.

In general, either there should be support for negative ranges, or ranges
might be end-exclusve, but not two at the same time, as having them both
together dramatically increases complexity.
Range is not Serializable

Currently ranges are not Serializable. This is due to difficulties
regarding using non-serializable interfaces, like ChronoDateTIme  in sample
implementation.
Alternatives

   - Restrict range type variable to implement Serializable. I see this
   option as undesiarable bacause of how much it narrows use of interface.

Current interface methods list is minimal

For now, API proposed contains minimal amount of methods that are used in
range arithmetics. List of methods is supposed to change as discussion
moves on.
Generic Range class vs Rnage interface + specific inmplementations

Currently, approach is to define interface and list of implementations.
Advantages

   - Ability to introduce specialized for type of range methods. For
   example, Timespan could have Duration toDuration() method, potential
   IntegerRange could have something like LongRange toLongRange() dur to
   limitations of comparability between classes. This would be impossible with
   structural class Range without declaring additional static utility methods.
   - Enhanced validation of annotaion targets as classes, unlike generics,
   arent erased.

Disadvantages

   - Increased amount of classes to maintain.
   - Additional considerations would be required before extending Range
   interface in case if hierarchy non-sealed to ensure backward compatibility.

API DescriptionNB: Since date ranges is supposed to be one of the most
popular if not the most popular use case for range, date-time libraries
were main reference for interface design.
------------------------------
Section: BoundsGeneral notes

   - In *Boost Date_Time* (time_period.begin()), the start and end are
   always defined, meaning there is no concept of unbounded intervals.
   Similarly, some libraries like *Chrono* in Rust assume bounded intervals
   by default. In fact, only a few libraries expose trully unbound ranges.
   Although, while complexity of implementation is increased by this corner
   cases, thier performance also vastly increased by cutting amount of
   operations in each method at least in half (For two-way unbound interval,
   almost all operations return constnat value).

------------------------------
T start()

*Description:*
Returns the start of the range. If the range is unbounded at the start,
this method throws an UnsupportedOperationException. This can be
preemptively checked using isBoundedAtStart().

*Alternatives:*

   - Method could return Optional<T> instead of throwing an exception. I
   see this two approaches roughly identical in terms of pros/cons score, so
   suggestions are much appreciated.

------------------------------
T end()

*Description*:
Returns the end of the range. If the range is unbounded at the end, this
method throws an UnsupportedOperationException. Use isBoundedAtEnd() to
check if the range is bounded.

*Alternatives:*

   - Simallarly to start(), method could return Optional<T> instead of
   throwing an exception. I see this two approaches roughly identical in terms
   of pros/cons score, so suggestions are much appreciated.

------------------------------
boolean isBoundedAtStart()

*Description*:
Returns true if the range is bounded at the start. If unbounded, it returns
false, meaning calling start() will throw an UnsupportedOperationException.

*Alternatives*:

   - *Joda-Time*, *NodaTime*, *Luxon*, and *Moment.js* do not explicitly
   support unbounded intervals by default but can use null or special
   values to represent unbounded starts.
   - *Boost Date_Time* and *Chrono* don?t support unbounded ranges
   directly, so this method is unnecessary.

------------------------------
boolean isBoundedAtEnd()

*Description*:
Returns true if the range is bounded at the end. A false value means the
range is unbounded at the end, and calling end() will throw an
UnsupportedOperationException.

*Alternatives*:

   - Similar to isBoundedAtStart(), most libraries don?t have built-in
   unbounded intervals, but the concept can be simulated using null,
   minimal/maximal possible value etc. Pros and cons were described in API
   notes.

------------------------------
Section: boolean operationsboolean contains(T instant)

*Description*:
Returns true if the given instant falls within the start and end bounds of
the range, otherwise returns false.

*Similar Methods in other libraries*:

   - *NodaTime (Interval.Contains)*
   - *Joda-Time (Interval.contains)*
   - *Luxon (Interval.contains)*
   - *Boost Date_Time (time_period.contains())*
   - And many others...

*Differences with existing APIs*:

   - *Moment.js* doesn?t provide a direct contains method but the
   moment-range plugin adds this functionality with range.contains().

*Note*: this method is present in most interval implementations. Terefore,
I concider as basic and unremovable from the API.
------------------------------
boolean overlaps(Range<? extends T> other)

*Description*:
Checks if the current range overlaps with another range. Returns true if
the two ranges overlap, otherwise returns false.

*Similar Methods in other libraries*:

   - *NodaTime (Interval.Overlaps)*
   - *Joda-Time (Interval.overlaps)*
   - *Luxon (Interval.overlaps)*
   - *Boost Date_Time (time_period.intersects())*
   - And many others...

*Differences with existing APIs*:

   - *Moment.js*: The moment-range plugin provides a similar overlaps() method
   to check overlap.
   - *Chrono* relies on custom interval intersection logic.

*Note*: this method is present in most interval implementations. Terefore,
I concider as basic and unremovable from the API.
------------------------------
General notes on next two methods

Most of the libraries propose API like isBefore(T point) or do not provide
methods like this at all. Since current implementation throws an exception
if interval is not bounded, trivial check for isBefore could become 4-6
lines long. The question basically comes down to whether the Range class
should be more data-structure-like or object-like. I would argue that at
least isBefore(T moment) is required, especially since ranges can be
negative currently. Existence of boolean isBefore(Range<? extends T> other)and
similarisAfter` is up to discussion.
boolean isBefore(Range<? extends T> other)

*Description*:
Returns true if the current range is strictly before another range (i.e.,
ends before the other range starts).

*Differences with other libraries*:

   - *NodaTime*: You?d manually compare End of one interval with the Start of
   another.
   - *Joda-Time*: Manual comparison with Interval.getEnd() and
   Interval.getStart().
   - *Boost Date_Time* and *Chrono* would use custom logic to compare
   time_period or ranges of time, since they don?t have a direct equivalent
   of isBefore().

*Alternatives*

   - Most of the libraries propose API like isBefore(T point) or do not
   provide methods like this at all. Since current implementation throws an
   exception if interval is not bounded, trivial check for isBefore could
   become 4-6 lines long. The question basically comes down to whether the
   Range class should be more data-structure-like or object-like. I would
   argue that at least isBefore(T moment) is required, especially since
   ranges can be negative currently

------------------------------
boolean isAfter(Range<? extends T> other)

*Description*:
Returns true if the current range is strictly after another range (i.e.,
starts after the other range ends).

   - *Similar Methods*:
      - Similar to isBefore(), manual comparisons are used in *NodaTime*,
      *Joda-Time*, and *Luxon* an others.

------------------------------
boolean isBefore(T point)

*Description:*
Determines if the span ends before the given point. This is useful when you
need to check whether a time span occurs entirely before a specific point.

*Alternatives*:

   - Method could be removed from APi at all, if Range is desired to be
   skewed towards being data structure.

------------------------------
boolean isAfter(T point)

*Description:*
Determines if the span starts after the given point. This is useful when
you need to check whether a time span occurs entirely after a specific
point.

*Alternatives*:

   - Similarly to boolean isBefore(T point), method could be removed from
   APi at all, if Range is desired to be skewed towards being data structure.

------------------------------
boolean isNegative()

*Description*:
Returns true if the start of the range is after the end, indicating a
"negative" range.

*Alternatives:*

   - if concidered too niche, negatie timespans could be removed from model.

*Note:* this one is most questionable for me. Do we really need negative
ranges? This is most entirely required in numeric ranges and diagrams,
while introdcues huge complexity overhead for majority that doesnt need
this feature. Negativity might be confusing for users. Would love to hear
thoughs on this matter
------------------------------
Section: Range arithmeticsOptional<Range<T>> intersection(Range<? extends
T> other)

*Description*:
Returns the intersection of the current range with another range. If the
ranges do not overlap, the result is an empty Optional. If they overlap,
the intersection is returned.

*Similar Methods*:

   - *NodaTime (Interval.Intersection())*
   - *Moment.js (via moment-range, range.intersect())*
   - *Joda-Time (Interval.overlap())*
   - And many others...

*Differences with existing APIs*:

   - *Boost Date_Time* returns an empty time_period if no overlap exists,
   instead of an Optional. Some libraries return null (e.g., *NodaTime*).
   - Other libraries return null if intervals arent overlapping. This is
   undesrable, so optional returned instead.

*Note*: this method is present in most interval implementations. Terefore,
I concider as basic and unremovable from the API.
------------------------------
Range<T>[] union(Range<? extends T> other)

*Description*:
Returns the union of two ranges. If the ranges overlap, the result is a
single combined range. If they do not overlap, the result is an array of
two separate ranges.

*Differences with existing APIs*:

   - *NodaTime* and *Joda-Time* support similar logic using custom union
   handling.
   - *Boost Date_Time* has no built-in union() function but you can write
   custom logic to combine or separate intervals.

*Note*: Behaviour of this method is up to change. Currently, it returns
array for maximal performance, but it can (and most likely should) be
wrapped in some monadic class. As an alternative, there may be support for
non-continuous ranges (ones with gaps inside them), then this method should
return thise kind of range.
------------------------------
Optional<Range<T>> gap(Range<? extends T> other)

*Description*:
Returns the gap between two ranges, if they do not overlap. If they
overlap, the result is an empty Optional.

*Differences with existing APIs*:

   - *NodaTime* and *Joda-Time* support custom logic to calculate the gap
   using isBefore(), isAfter(), and manual calculations of the gap.
   - Other libraries return null if intervals are overlapping. This is
   undesrable, so optional returned instead.

------------------------------
Section: potential methodsboolean isEmpty()

*Description:*
Determines if the range is "empty,"

Empty range is its own, separate type of range (basically opposite of
unbounded range). There are many questions regrading this type of range. Is
it bounded at start or end? If so, what should start() or end() return.
Them throwing an exception would violate current contract between
IsBoundedAtX() and 'x()` methods.

*Advantages*

   - Returning empty range instead of Optional might be more user-friendly

*Disadvantages*

   - One more concept in the API model
   - Corner case in IsBoundedAtX() and 'x()` contract.

Potential Methods for API Enhancement

In this section, we explore methods that could be added to the API,
comparing them with similar functionality in popular time-related
libraries. These methods enhance the versatility and clarity of the
Range<T> implementation,
especially in the context of temporal, numeric, and other domain-specific
ranges. Some of these methods are inspired by well-established libraries,
while others are novel suggestions.
------------------------------
boolean encloses(Range<? extends T> other)

*Description*:
Checks whether the current range completely encloses another range, i.e.,
the other range starts after or at the start of the current range and ends
before or at the end of the current range.

   -

   *Similar Methods in Other Libraries*:
   - *NodaTime (Interval.ContainedBy)*
      - *Joda-Time (Interval.contains)*
      - *Luxon (Interval.contains)*
      - *Boost Date_Time (time_period.contains())*
   -

   *Differences with Existing APIs*:
   - Some libraries handle encloses() and contains() in the same method.
      For clarity, this API can separate the two, where contains() is used
      for checking individual points and encloses() is for range-level
      comparison.

------------------------------
boolean abuts(Range<? extends T> other)

*Description*:
Returns true if the current range abuts (i.e., touches but does not
overlap) with another range. This method is useful when determining whether
two ranges are adjacent but do not overlap.

   -

   *Similar Methods in Other Libraries*:
   - *NodaTime (Interval.Abuts)*
   -

   *Alternatives*:
   - Instead of this method, users could manually compare the end of one
      range and the start of another, but including abuts() in the API
      simplifies the logic and reduces error-prone comparisons.

------------------------------
Range<T> extendTo(T point)

*Description*:
Returns a new range that extends the current range to include the given
point. If the point is already within the range, it returns the current
range. Otherwise, it extends either the start or end, depending on the
point's position relative to the range.

   -

   *Similar Methods in Other Libraries*:
   - *NodaTime* and *Joda-Time* do not have explicit methods for this, but
      users can manipulate intervals manually.
      - *Moment.js*: The moment-range plugin offers similar logic via
      manual adjustments to the range.
   -

   *Advantages*:
   - In contrast to manual adjustment, this method automates the process of
      extending ranges, which can be useful in situations where ranges
need to be
      dynamically modified over time (e.g., expanding time intervals
in streaming
      data).

*Alternatives*:

   - Users could manually adjust the range using start() and end() "withers",
   but an explicit extendTo() method offers a more intuitive, built-in
   approach

------------------------------
Range<T> shrinkTo(T point)

*Description*:
Returns a new range that shrinks the current range to exclude the given
point, if possible. If the point is within the range, the range is modified
so that it no longer includes the point. This is useful for splitting
ranges or excluding unwanted time periods or values.

   - *Similar Methods in Other Libraries*:
   No major time libraries provide a direct equivalent to this
   functionality, although similar operations can be manually performed by
   manipulating start and end.

*Alternatives*:

   - Similarly to extendTo, users could manually adjust the range using
   start() and end() "withers", but an explicit shrinkTo() method offers a
   more intuitive, built-in approach.

------------------------------
Range<T>[] difference(Range<? extends T> other)

*Description*:
Returns the difference between the current range and another range (XOR
operations). If the ranges overlap, the result is a new range or two ranges
representing the non-overlapping portions. If the ranges do not overlap,
the result is the current range.

*Adavntages*:

   - This method simplifies computing the difference between two ranges,
   reducing the need for manual boundary comparisons.
   - Completes set of methods required for ranges arithmetics

*Disdavntages*:

   - THis method is inverse of union(Range<? extends T> other), so it has
   same design problems as union.

------------------------------
Range<T> clamp(Range<? extends T> bounds)

*Description*:
Clamps the current range to fit within the specified bounds. If the current
range extends outside of the bounds, it is shortened to fit within the
bounds. If the range already fits within the bounds, it is returned
unchanged.

*Advantages*:

   - This method streamlines the process of adjusting a range to a set of
   bounds, which is especially useful in time-based operations where ranges
   must be constrained within specific periods (e.g., scheduling).

------------------------------
boolean isContiguousWith(Range<? extends T> other)

*Description*:
Determines if the current range is contiguous with another range, meaning
that the two ranges touch or overlap without leaving any gaps. This is
particularly useful when combining ranges or ensuring that a sequence of
ranges forms a continuous block.

*Alternatives*:

   - Users could manually compare the end and start of ranges to check
   contiguity, but this method offers a more explicit and efficient way to
   perform the check.

------------------------------
Optional<Range<T>> asBounded()

*Description*:
Returns the bounded version of the current range, if one exists. If the
range is already bounded, it returns the range unchanged. If the range is
unbounded, the result is an empty Optional. Could be used as a monade for
handling errors if range that is expected to be bounded, but unbounded one
has been recieved.

*Alternatives:*

   - API could explicitly expose BoundedRange marker (or not marker)
   interface to verify range that is recieved is bounded at compile time.
   Interface could provide some adapter methods for converting
   unknown-boundness ranges to bounded, and have specific behaviour for error
   cases.

Range<T>[] splitAt(T point)

*Description*: Splits the current range into two sub-ranges at the
specified point. If the point lies outside the range, it returns an array
of length 1 with initial range. If rang contains() point, than array of
length 2 is returned, whith two ranges splitted accross given point.
List<Range<T>> splitInto(int n)

*Description*:
Splits the current range into n equal sub-ranges. If the range cannot be
evenly divided, the last range may be slightly larger to accommodate the
remaining span. Throws UnsupportedOperationException if range is at least
half-unbounded.
Stream<T> pointsFromStartToEnd(??? step)

*Description*: Returns a list of points that are evenly spaced from the
start to the end of the range, using the specified step size. Throws
UnsupportedOperationException if range is isBoundedAtStart() returns false.

*Note:* while this method could have various use cases, It is not clear how
step could be provided. One of the options is to pass Function<T, T> that
is invoked on each value until value is > end() instrad of constant step.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/a28f0e15/attachment-0001.htm>

From forax at univ-mlv.fr  Sun Sep 22 20:17:14 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 22 Sep 2024 22:17:14 +0200 (CEST)
Subject: Range API
In-Reply-To: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
Message-ID: <7528157.13866079.1727036234104.JavaMail.zimbra@univ-eiffel.fr>

Hello, 
if we introduce a Range object, it will have to be an immutable class because otherwise any API that takes an interface Range as parameter will have to copy it into an immutable subclass first; 

In term of design, coupling different parts of the JDK with an interface is not appealing to me, especially given that a Range is a very small object. 

We (the amber EG) have talked about adding a way to do pattern matching using a Range with a special syntax like 1 .. 3, if we introduce such syntax, the runtime representation will be an immutable class an not an interface (think java.lang.String). 

Your API is unsafe, you can not have a method that creates a Range<T>[] in a safe way, the combination of erasure + array covariant is nasty (at least until we have a way to create a read-only arrays). 

regards, 
R?mi 

> From: "Olexandr Rotan" <rotanolexandr842 at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, September 22, 2024 9:01:47 PM
> Subject: Range API

> Hello everyone! I am writing here today to invite everyone to participate in the
> discussion regarding the Range APi proposal I have made into JDK. Here is the
> pull request link: [ https://github.com/openjdk/jdk/pull/21122 |
> https://github.com/openjdk/jdk/pull/21122 ] , and PR text:

> This pull request describes the methods of the Range<T> interface. The Range<T>
> interface represents a bounded or unbounded range. (From now on, range, span
> and interval are used interchangeably, but docs only use "range") Goals:

>     *

> Main goal. Standardization of the Range/Interval API: The primary objective of
> this effort is to provide a standardized interface for working with ranges or
> spans of time (or any ordered types). Many existing libraries offer their own
> custom implementations of ranges, and they differ in significant ways, making
> it harder to use and combine across different codebases. Standardization will
> ensure consistency, interoperability, and a more predictable interface across
> various contexts.
>     *

> Versatile range operations: provide a comprehensive API for manipulating and
> querying ranges, especially those representing time periods or numerical
> intervals. The API simplifies common tasks like checking containment, overlaps,
> or adjacency between ranges.
>     *

> Support for unbounded ranges: Unlike many existing libraries, which assume
> intervals are always bounded, this API aims to fully support unbounded
> intervals. Users will be able to define ranges with open starts or ends, making
> it suitable for temporal data that spans indefinitely in one direction, such as
> future projections or historical data with unknown starting points.
>     *

> Performance efficiency: The API aims to provide optimized for performance
> implementation, that takes advantage of all possible simplifications and
> short-circuits.
>     *

> Consistency with existing libraries: To aid adoption, the API should be familiar
> to developers who have used popular libraries like NodaTime, Joda-Time,
> Three-Ten Extra, and Boost Date_Time, but with enhancements for unbounded
> intervals, negative ranges (?), and optional return types instead of null
> values.

> Non-Goals:

>     *

> Handling complex data structures beyond smple ranges: This API is not intended
> to manage or represent complex data structures beyond ranges. For example,
> ranges that involve intricate internal states, like non-contiguous ranges (?)
> or ranges with multiple gaps, are out of scope.
>     *

> Overly simplifying range types: While ease of use is a goal, its is not an aim
> to remove support for advanced cases like unbounded or negative ranges, even if
> this results in slightly more complex implementations. The API should not be
> skewed towards being purely a simple data structure for bounded ranges.
>     *

> Application-specific logic: The API is meant to be domain-agnostic and
> general-purpose. It is not intended to allow to embed application-specific
> logic, such as calendar-based date manipulations or domain-specific business
> rules for interval comparison.
>     *

> Replacing existing libraries: The goal is not to replace established libraries
> like Joda-Time or ThreeTen-Extra, but rather to augment these ideas with
> support for unbounded ranges and additional arithmetic operations. Although, it
> is a goal to provide interface that could exisiting libraries could easily
> retrofit into.

> Motivation

> The primary motivation behind standardizing the Range API is the lack of an
> established, universal interface for handling ranges or spans across various
> domains. Developers are often forced to work with different, incompatible range
> implementations across libraries or to re-implement common functionality
> themselves. This leads to redundant code, increased dependencies, and greater
> chances for errors.

> In many software systems?whether in scheduling, auditing, access control, or
> financial services?ranges are used to represent periods of time, numerical
> intervals, or validity spans. Without a standardized API, developers must
> contend with diverse implementations that often differ in naming conventions,
> behavior, and supported features. These variations create unnecessary
> complexity, as developers must:

>     1.

> Introduce additional dependencies : Many libraries provide similar functionality
> for ranges, but since they are not interchangeable, developers must often add
> extra dependencies to cover edge cases or specific use cases that are not
> available in a single library. This bloats the codebase and creates maintenance
> overhead.
>     2.

> Re-implement common logic : In cases where no single library meets the required
> needs, developers are forced to write their own range-handling logic. This
> reinvention of basic operations such as intersection, union, or containment
> leads to redundancy, increased likelihood of bugs, and inconsistency in how
> ranges are handled across different parts of the code.
>     3.

> Fragmentation across domains : Different libraries often define their own range
> concepts (e.g., for date-times, numbers, or general comparisons), which are
> rarely compatible with one another. This lack of compatibility makes
> integration between systems difficult, requiring custom adapters or
> conversions.

> By defining a standard Range API, the goal is to:

>    * Reduce the dependency footprint: A common, well-designed API for ranges would
>    eliminate the need to import multiple libraries just to handle different types
>     of ranges, reducing dependencies in projects and enhancing maintainability.
>    * Simplify code and increase reusability: With a standardized interface,
>    developers can write range-related code once and reuse it across projects and
>    libraries, confident that the same semantics and operations will apply
>     consistently.
>    * Minimize developer errors: By providing a predictable and well-documented
>    interface, the likelihood of misunderstandings or incorrect use of range
>    operations will decrease. Developers can trust that operations like
>    intersections, unions, and comparisons will behave consistently, regardless of
>     the context.

> In essence, the lack of standardization in range operations creates unnecessary
> complexity, fragmentation, and redundant effort. A standardized Range API would
> provide clarity, reduce the need for additional dependencies, and enable more
> efficient, reusable, and error-free code across different projects and domains.
> Key API points
> Support of unbounded intervals

> API supports both one- and two-sided. Provided sample (draft) implementation for
> ChronoDateTime has 4 separate implementation for each type of ranges.
> Alternatives

>    * Many Libraries, like Luxon, C++ boost, NodaTime and many others, arguably the
>    most, fo not explicitly support unbounded intervals. This reduces complexity of
>    implementation, but takes away many possible optimization for edge-cases.
>    Alternative they propose is to use Instant.MIN and Instant.MAX or similar to
>     create unbounded-like intervals.

> Support for negative intervals,

> API supports both positive and negative and positive ranges. This is
> questionable and discussion is encouraged. Advantages

>    * Allows more flexible usage of API, which would be helpful for use cases like
>     diagrams visualization.

> Disadvantages

>     * Dramatically increases amount of boilerplate code inside the implementations.
>    * Makes behaviour of potential methods like boolean endsBefore(T t) unintuitive.
>    Does this mean that end() is before that provided parameter, or latter of
>     bounds (i.e. start() for negative range and end() for positive).
>    * Limited usability scope. Most use cases would not benefit from possibility of
>     negative ranges creation, but would have to suffer performance decrease.

> In general, either there should be support for negative ranges, or ranges might
> be end-exclusve, but not two at the same time, as having them both together
> dramatically increases complexity. Range is not Serializable

> Currently ranges are not Serializable . This is due to difficulties regarding
> using non-serializable interfaces, like ChronoDateTIme in sample
> implementation. Alternatives

>    * Restrict range type variable to implement Serializable . I see this option as
>     undesiarable bacause of how much it narrows use of interface.

> Current interface methods list is minimal

> For now, API proposed contains minimal amount of methods that are used in range
> arithmetics. List of methods is supposed to change as discussion moves on.
> Generic Range class vs Rnage interface + specific inmplementations

> Currently, approach is to define interface and list of implementations.
> Advantages

>    * Ability to introduce specialized for type of range methods. For example,
>    Timespan could have Duration toDuration() method, potential IntegerRange could
>    have something like LongRange toLongRange() dur to limitations of comparability
>    between classes. This would be impossible with structural class Range without
>     declaring additional static utility methods.
>    * Enhanced validation of annotaion targets as classes, unlike generics, arent
>     erased.

> Disadvantages

>     * Increased amount of classes to maintain.
>    * Additional considerations would be required before extending Range interface
>     in case if hierarchy non-sealed to ensure backward compatibility.

> API Description
> NB: Since date ranges is supposed to be one of the most popular if not the most
> popular use case for range, date-time libraries were main reference for
> interface design.

> Section: Bounds
> General notes

>    * In Boost Date_Time ( time_period.begin() ), the start and end are always
>    defined, meaning there is no concept of unbounded intervals. Similarly, some
>    libraries like Chrono in Rust assume bounded intervals by default. In fact,
>    only a few libraries expose trully unbound ranges. Although, while complexity
>    of implementation is increased by this corner cases, thier performance also
>    vastly increased by cutting amount of operations in each method at least in
>    half (For two-way unbound interval, almost all operations return constnat
>     value).

> T start()

> Description:
> Returns the start of the range. If the range is unbounded at the start, this
> method throws an UnsupportedOperationException . This can be preemptively
> checked using isBoundedAtStart() .

> Alternatives:

>    * Method could return Optional<T> instead of throwing an exception. I see this
>    two approaches roughly identical in terms of pros/cons score, so suggestions
>     are much appreciated.

> T end()

> Description :
> Returns the end of the range. If the range is unbounded at the end, this method
> throws an UnsupportedOperationException . Use isBoundedAtEnd() to check if the
> range is bounded.

> Alternatives:

>    * Simallarly to start(), method could return Optional<T> instead of throwing an
>    exception. I see this two approaches roughly identical in terms of pros/cons
>     score, so suggestions are much appreciated.

> boolean isBoundedAtStart()

> Description :
> Returns true if the range is bounded at the start. If unbounded, it returns
> false , meaning calling start() will throw an UnsupportedOperationException .

> Alternatives :

>    * Joda-Time , NodaTime , Luxon , and Moment.js do not explicitly support
>    unbounded intervals by default but can use null or special values to represent
>     unbounded starts.
>    * Boost Date_Time and Chrono don?t support unbounded ranges directly, so this
>     method is unnecessary.

> boolean isBoundedAtEnd()

> Description :
> Returns true if the range is bounded at the end. A false value means the range
> is unbounded at the end, and calling end() will throw an
> UnsupportedOperationException .

> Alternatives :

>    * Similar to isBoundedAtStart() , most libraries don?t have built-in unbounded
>    intervals, but the concept can be simulated using null , minimal/maximal
>     possible value etc. Pros and cons were described in API notes.

> Section: boolean operations
> boolean contains(T instant)

> Description :
> Returns true if the given instant falls within the start and end bounds of the
> range, otherwise returns false .

> Similar Methods in other libraries :

>     * NodaTime ( Interval.Contains )
>     * Joda-Time ( Interval.contains )
>     * Luxon ( Interval.contains )
>     * Boost Date_Time ( time_period.contains() )
>     * And many others...

> Differences with existing APIs :

>    * Moment.js doesn?t provide a direct contains method but the moment-range plugin
>     adds this functionality with range.contains() .

> Note : this method is present in most interval implementations. Terefore, I
> concider as basic and unremovable from the API.
> boolean overlaps(Range<? extends T> other)

> Description :
> Checks if the current range overlaps with another range. Returns true if the two
> ranges overlap, otherwise returns false .

> Similar Methods in other libraries :

>     * NodaTime ( Interval.Overlaps )
>     * Joda-Time ( Interval.overlaps )
>     * Luxon ( Interval.overlaps )
>     * Boost Date_Time ( time_period.intersects() )
>     * And many others...

> Differences with existing APIs :

>    * Moment.js : The moment-range plugin provides a similar overlaps() method to
>     check overlap.
>     * Chrono relies on custom interval intersection logic.

> Note : this method is present in most interval implementations. Terefore, I
> concider as basic and unremovable from the API.
> General notes on next two methods

> Most of the libraries propose API like isBefore(T point) or do not provide
> methods like this at all. Since current implementation throws an exception if
> interval is not bounded, trivial check for isBefore could become 4-6 lines
> long. The question basically comes down to whether the Range class should be
> more data-structure-like or object-like. I would argue that at least isBefore(T
> moment) is required, especially since ranges can be negative currently.
> Existence of boolean isBefore(Range<? extends T> other) and similar isAfter` is
> up to discussion. boolean isBefore(Range<? extends T> other)

> Description :
> Returns true if the current range is strictly before another range (i.e., ends
> before the other range starts).

> Differences with other libraries :

>    * NodaTime : You?d manually compare End of one interval with the Start of
>     another.
>     * Joda-Time : Manual comparison with Interval.getEnd() and Interval.getStart() .
>    * Boost Date_Time and Chrono would use custom logic to compare time_period or
>     ranges of time, since they don?t have a direct equivalent of isBefore() .

> Alternatives

>    * Most of the libraries propose API like isBefore(T point) or do not provide
>    methods like this at all. Since current implementation throws an exception if
>    interval is not bounded, trivial check for isBefore could become 4-6 lines
>    long. The question basically comes down to whether the Range class should be
>    more data-structure-like or object-like. I would argue that at least isBefore(T
>     moment) is required, especially since ranges can be negative currently

> boolean isAfter(Range<? extends T> other)

> Description :
> Returns true if the current range is strictly after another range (i.e., starts
> after the other range ends).

>     * Similar Methods :
>        * Similar to isBefore() , manual comparisons are used in NodaTime , Joda-Time ,
>         and Luxon an others.

> boolean isBefore(T point)

> Description:
> Determines if the span ends before the given point. This is useful when you need
> to check whether a time span occurs entirely before a specific point.

> Alternatives :

>    * Method could be removed from APi at all, if Range is desired to be skewed
>     towards being data structure.

> boolean isAfter(T point)

> Description:
> Determines if the span starts after the given point. This is useful when you
> need to check whether a time span occurs entirely after a specific point.

> Alternatives :

>    * Similarly to boolean isBefore(T point) , method could be removed from APi at
>     all, if Range is desired to be skewed towards being data structure.

> boolean isNegative()

> Description :
> Returns true if the start of the range is after the end, indicating a "negative"
> range.

> Alternatives:

>     * if concidered too niche, negatie timespans could be removed from model.

> Note: this one is most questionable for me. Do we really need negative ranges?
> This is most entirely required in numeric ranges and diagrams, while introdcues
> huge complexity overhead for majority that doesnt need this feature. Negativity
> might be confusing for users. Would love to hear thoughs on this matter
> Section: Range arithmetics
> Optional<Range<T>> intersection(Range<? extends T> other)

> Description :
> Returns the intersection of the current range with another range. If the ranges
> do not overlap, the result is an empty Optional . If they overlap, the
> intersection is returned.

> Similar Methods :

>     * NodaTime ( Interval.Intersection() )
>     * Moment.js (via moment-range , range.intersect() )
>     * Joda-Time ( Interval.overlap() )
>     * And many others...

> Differences with existing APIs :

>    * Boost Date_Time returns an empty time_period if no overlap exists, instead of
>     an Optional . Some libraries return null (e.g., NodaTime ).
>    * Other libraries return null if intervals arent overlapping. This is
>     undesrable, so optional returned instead.

> Note : this method is present in most interval implementations. Terefore, I
> concider as basic and unremovable from the API.
> Range<T>[] union(Range<? extends T> other)

> Description :
> Returns the union of two ranges. If the ranges overlap, the result is a single
> combined range. If they do not overlap, the result is an array of two separate
> ranges.

> Differences with existing APIs :

>     * NodaTime and Joda-Time support similar logic using custom union handling.
>    * Boost Date_Time has no built-in union() function but you can write custom
>     logic to combine or separate intervals.

> Note : Behaviour of this method is up to change. Currently, it returns array for
> maximal performance, but it can (and most likely should) be wrapped in some
> monadic class. As an alternative, there may be support for non-continuous
> ranges (ones with gaps inside them), then this method should return thise kind
> of range.
> Optional<Range<T>> gap(Range<? extends T> other)

> Description :
> Returns the gap between two ranges, if they do not overlap. If they overlap, the
> result is an empty Optional .

> Differences with existing APIs :

>    * NodaTime and Joda-Time support custom logic to calculate the gap using
>     isBefore() , isAfter() , and manual calculations of the gap.
>    * Other libraries return null if intervals are overlapping. This is undesrable,
>     so optional returned instead.

> Section: potential methods
> boolean isEmpty()

> Description:
> Determines if the range is "empty,"

> Empty range is its own, separate type of range (basically opposite of unbounded
> range). There are many questions regrading this type of range. Is it bounded at
> start or end? If so, what should start() or end() return. Them throwing an
> exception would violate current contract between IsBoundedAtX() and 'x()`
> methods.

> Advantages

>     * Returning empty range instead of Optional might be more user-friendly

> Disadvantages

>     * One more concept in the API model
>     * Corner case in IsBoundedAtX() and 'x()` contract.

> Potential Methods for API Enhancement

> In this section, we explore methods that could be added to the API, comparing
> them with similar functionality in popular time-related libraries. These
> methods enhance the versatility and clarity of the Range<T> implementation,
> especially in the context of temporal, numeric, and other domain-specific
> ranges. Some of these methods are inspired by well-established libraries, while
> others are novel suggestions.
> boolean encloses(Range<? extends T> other)

> Description :
> Checks whether the current range completely encloses another range, i.e., the
> other range starts after or at the start of the current range and ends before
> or at the end of the current range.

>     *

> Similar Methods in Other Libraries :
>         * NodaTime ( Interval.ContainedBy )
>         * Joda-Time ( Interval.contains )
>         * Luxon ( Interval.contains )
>         * Boost Date_Time ( time_period.contains() )
>     *

> Differences with Existing APIs :
>        * Some libraries handle encloses() and contains() in the same method. For
>        clarity, this API can separate the two, where contains() is used for checking
>         individual points and encloses() is for range-level comparison.

> boolean abuts(Range<? extends T> other)

> Description :
> Returns true if the current range abuts (i.e., touches but does not overlap)
> with another range. This method is useful when determining whether two ranges
> are adjacent but do not overlap.

>     *

> Similar Methods in Other Libraries :
>         * NodaTime ( Interval.Abuts )
>     *

> Alternatives :
>        * Instead of this method, users could manually compare the end of one range and
>        the start of another, but including abuts() in the API simplifies the logic and
>         reduces error-prone comparisons.

> Range<T> extendTo(T point)

> Description :
> Returns a new range that extends the current range to include the given point.
> If the point is already within the range, it returns the current range.
> Otherwise, it extends either the start or end, depending on the point's
> position relative to the range.

>     *

> Similar Methods in Other Libraries :
>        * NodaTime and Joda-Time do not have explicit methods for this, but users can
>         manipulate intervals manually.
>        * Moment.js : The moment-range plugin offers similar logic via manual
>         adjustments to the range.
>     *

> Advantages :
>        * In contrast to manual adjustment, this method automates the process of
>        extending ranges, which can be useful in situations where ranges need to be
>        dynamically modified over time (e.g., expanding time intervals in streaming
>         data).

> Alternatives :

>    * Users could manually adjust the range using start() and end() "withers", but
>     an explicit extendTo() method offers a more intuitive, built-in approach

> Range<T> shrinkTo(T point)

> Description :
> Returns a new range that shrinks the current range to exclude the given point,
> if possible. If the point is within the range, the range is modified so that it
> no longer includes the point. This is useful for splitting ranges or excluding
> unwanted time periods or values.

>    * Similar Methods in Other Libraries : No major time libraries provide a direct
>    equivalent to this functionality, although similar operations can be manually
>     performed by manipulating start and end .

> Alternatives :

>    * Similarly to extendTo , users could manually adjust the range using start()
>    and end() "withers", but an explicit shrinkTo() method offers a more intuitive,
>     built-in approach.

> Range<T>[] difference(Range<? extends T> other)

> Description :
> Returns the difference between the current range and another range (XOR
> operations). If the ranges overlap, the result is a new range or two ranges
> representing the non-overlapping portions. If the ranges do not overlap, the
> result is the current range.

> Adavntages :

>    * This method simplifies computing the difference between two ranges, reducing
>     the need for manual boundary comparisons.
>     * Completes set of methods required for ranges arithmetics

> Disdavntages :

>    * THis method is inverse of union(Range<? extends T> other) , so it has same
>     design problems as union.

> Range<T> clamp(Range<? extends T> bounds)

> Description :
> Clamps the current range to fit within the specified bounds. If the current
> range extends outside of the bounds, it is shortened to fit within the bounds.
> If the range already fits within the bounds, it is returned unchanged.

> Advantages :

>    * This method streamlines the process of adjusting a range to a set of bounds,
>    which is especially useful in time-based operations where ranges must be
>     constrained within specific periods (e.g., scheduling).

> boolean isContiguousWith(Range<? extends T> other)

> Description :
> Determines if the current range is contiguous with another range, meaning that
> the two ranges touch or overlap without leaving any gaps. This is particularly
> useful when combining ranges or ensuring that a sequence of ranges forms a
> continuous block.

> Alternatives :

>    * Users could manually compare the end and start of ranges to check contiguity,
>     but this method offers a more explicit and efficient way to perform the check.

> Optional<Range<T>> asBounded()

> Description :
> Returns the bounded version of the current range, if one exists. If the range is
> already bounded, it returns the range unchanged. If the range is unbounded, the
> result is an empty Optional . Could be used as a monade for handling errors if
> range that is expected to be bounded, but unbounded one has been recieved.

> Alternatives:

>    * API could explicitly expose BoundedRange marker (or not marker) interface to
>    verify range that is recieved is bounded at compile time. Interface could
>    provide some adapter methods for converting unknown-boundness ranges to
>     bounded, and have specific behaviour for error cases.

> Range<T>[] splitAt(T point)

> Description : Splits the current range into two sub-ranges at the specified
> point. If the point lies outside the range, it returns an array of length 1
> with initial range. If rang contains() point, than array of length 2 is
> returned, whith two ranges splitted accross given point. List<Range<T>>
> splitInto(int n)

> Description :
> Splits the current range into n equal sub-ranges. If the range cannot be evenly
> divided, the last range may be slightly larger to accommodate the remaining
> span. Throws UnsupportedOperationException if range is at least half-unbounded.
> Stream<T> pointsFromStartToEnd(??? step)

> Description : Returns a list of points that are evenly spaced from the start to
> the end of the range, using the specified step size. Throws
> UnsupportedOperationException if range is isBoundedAtStart() returns false.

> Note: while this method could have various use cases, It is not clear how step
> could be provided. One of the options is to pass Function<T, T> that is invoked
> on each value until value is > end( ) instrad of constant step.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/13455db2/attachment-0001.htm>

From rotanolexandr842 at gmail.com  Sun Sep 22 20:52:59 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Sun, 22 Sep 2024 23:52:59 +0300
Subject: Range API
In-Reply-To: <7528157.13866079.1727036234104.JavaMail.zimbra@univ-eiffel.fr>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <7528157.13866079.1727036234104.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAL5bRt_d-SjK=nMJGGrLV15KuPDF7p=MYw0v9W6zTjNO1R616w@mail.gmail.com>

Hello!
Thanks for your comments, they are valuable to me. I indeed intended to
make Range immutable, if you noticed, in potential methods I listed
extendTo and shrinkTo, which is kind of modified with-ers. But, it's indeed
better to convert range to class and expose some methods to create bounded
and unbounded ones.

The range pattern would be great to have, but unless there is some way to
ger range object, there will not me a way to create range arithmetics. It
would be better, in my opinion, to create member pattern inside Range class
that can match it's type params. This may eliminate need for new syntax for
range litterals and make feature more versatile.

Regarding the array return types, I specifically mentioned that this is the
first thing up to change. Your point is completely valid, I will look into
this issue as soon as possible.

I don't really understand the point about coupling different parts with an
interface (future class I guess). Do you say that it is not desirable to
have specialized versions of range such as timespan, and would prefer just
one generic Range?

I appreciate all feedback you give. I will address your comments as soon as
possible. I am new to API design, so I guess people won't go to hard on me.
I hope that, iteratively, I could workout the API that would be a good
match for JDK quality level.

Best regards

On Sun, Sep 22, 2024, 23:17 Remi Forax <forax at univ-mlv.fr> wrote:

> Hello,
> if we introduce a Range object, it will have to be an immutable class
> because otherwise any API that takes an interface Range as parameter will
> have to copy it into an immutable subclass first;
>
> In term of design, coupling different parts of the JDK with an interface
> is not appealing to me, especially given that a Range is a very small
> object.
>
> We (the amber EG) have talked about adding a way to do pattern matching
> using a Range with a special syntax like 1 .. 3, if we introduce such
> syntax, the runtime representation will be an immutable class an not an
> interface (think java.lang.String).
>
> Your API is unsafe, you can not have a method that creates a Range<T>[] in
> a safe way, the combination of erasure + array covariant is nasty (at least
> until we have a way to create a read-only arrays).
>
> regards,
> R?mi
>
> ------------------------------
>
> *From: *"Olexandr Rotan" <rotanolexandr842 at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Sunday, September 22, 2024 9:01:47 PM
> *Subject: *Range API
>
> Hello everyone! I am writing here today to invite everyone to participate
> in the discussion regarding the Range APi proposal I have made into JDK.
> Here is the pull request link: https://github.com/openjdk/jdk/pull/21122,
> and PR text:
>
> This pull request describes the methods of the Range<T> interface. The
> Range<T> interface represents a bounded or unbounded range. (From now on,
> range, span and interval are used interchangeably, but docs only use
> "range")
> Goals:
>
>    -
>
>    *Main goal. Standardization of the Range/Interval API:* The primary
>    objective of this effort is to provide a standardized interface for working
>    with ranges or spans of time (or any ordered types). Many existing
>    libraries offer their own custom implementations of ranges, and they differ
>    in significant ways, making it harder to use and combine across different
>    codebases. Standardization will ensure consistency, interoperability, and a
>    more predictable interface across various contexts.
>    -
>
>    *Versatile range operations:* provide a comprehensive API for
>    manipulating and querying ranges, especially those representing time
>    periods or numerical intervals. The API simplifies common tasks like
>    checking containment, overlaps, or adjacency between ranges.
>    -
>
>    *Support for unbounded ranges:* Unlike many existing libraries, which
>    assume intervals are always bounded, this API aims to fully support
>    unbounded intervals. Users will be able to define ranges with open starts
>    or ends, making it suitable for temporal data that spans indefinitely in
>    one direction, such as future projections or historical data with unknown
>    starting points.
>    -
>
>    *Performance efficiency:* The API aims to provide optimized for
>    performance implementation, that takes advantage of all possible
>    simplifications and short-circuits.
>    -
>
>    *Consistency with existing libraries:* To aid adoption, the API should
>    be familiar to developers who have used popular libraries like NodaTime,
>    Joda-Time, Three-Ten Extra, and Boost Date_Time, but with enhancements for
>    unbounded intervals, negative ranges (?), and optional return types instead
>    of null values.
>
> Non-Goals:
>
>    -
>
>    *Handling complex data structures beyond smple ranges:* This API is
>    not intended to manage or represent complex data structures beyond ranges.
>    For example, ranges that involve intricate internal states, like
>    non-contiguous ranges (?) or ranges with multiple gaps, are out of scope.
>    -
>
>    *Overly simplifying range types:* While ease of use is a goal, its is
>    not an aim to remove support for advanced cases like unbounded or negative
>    ranges, even if this results in slightly more complex implementations. The
>    API should not be skewed towards being purely a simple data structure for
>    bounded ranges.
>    -
>
>    *Application-specific logic:* The API is meant to be domain-agnostic
>    and general-purpose. It is not intended to allow to embed
>    application-specific logic, such as calendar-based date manipulations or
>    domain-specific business rules for interval comparison.
>    -
>
>    *Replacing existing libraries:* The goal is not to replace established
>    libraries like Joda-Time or ThreeTen-Extra, but rather to augment these
>    ideas with support for unbounded ranges and additional arithmetic
>    operations. Although, it is a goal to provide interface that could
>    exisiting libraries could easily retrofit into.
>
> Motivation
>
> The primary motivation behind standardizing the Range API is the *lack of
> an established, universal interface* for handling ranges or spans across
> various domains. Developers are often forced to work with different,
> incompatible range implementations across libraries or to re-implement
> common functionality themselves. This leads to redundant code, increased
> dependencies, and greater chances for errors.
>
> In many software systems?whether in scheduling, auditing, access control,
> or financial services?ranges are used to represent periods of time,
> numerical intervals, or validity spans. Without a standardized API,
> developers must contend with diverse implementations that often differ in
> naming conventions, behavior, and supported features. These variations
> create unnecessary complexity, as developers must:
>
>    1.
>
>    *Introduce additional dependencies*: Many libraries provide similar
>    functionality for ranges, but since they are not interchangeable,
>    developers must often add extra dependencies to cover edge cases or
>    specific use cases that are not available in a single library. This bloats
>    the codebase and creates maintenance overhead.
>    2.
>
>    *Re-implement common logic*: In cases where no single library meets
>    the required needs, developers are forced to write their own range-handling
>    logic. This reinvention of basic operations such as intersection, union, or
>    containment leads to redundancy, increased likelihood of bugs, and
>    inconsistency in how ranges are handled across different parts of the code.
>    3.
>
>    *Fragmentation across domains*: Different libraries often define their
>    own range concepts (e.g., for date-times, numbers, or general comparisons),
>    which are rarely compatible with one another. This lack of compatibility
>    makes integration between systems difficult, requiring custom adapters or
>    conversions.
>
> By defining a standard Range API, the goal is to:
>
>    - *Reduce the dependency footprint:* A common, well-designed API for
>    ranges would eliminate the need to import multiple libraries just to handle
>    different types of ranges, reducing dependencies in projects and enhancing
>    maintainability.
>    - *Simplify code and increase reusability:* With a standardized
>    interface, developers can write range-related code once and reuse it across
>    projects and libraries, confident that the same semantics and operations
>    will apply consistently.
>    - *Minimize developer errors:* By providing a predictable and
>    well-documented interface, the likelihood of misunderstandings or incorrect
>    use of range operations will decrease. Developers can trust that operations
>    like intersections, unions, and comparisons will behave consistently,
>    regardless of the context.
>
> In essence, the lack of standardization in range operations creates
> unnecessary complexity, fragmentation, and redundant effort. A standardized
> Range API would provide clarity, reduce the need for additional
> dependencies, and enable more efficient, reusable, and error-free code
> across different projects and domains.
> Key API pointsSupport of unbounded intervals
>
> API supports both one- and two-sided. Provided sample (draft)
> implementation for ChronoDateTime has 4 separate implementation for each
> type of ranges.
> Alternatives
>
>    - Many Libraries, like Luxon, C++ boost, NodaTime and many others,
>    arguably the most, fo not explicitly support unbounded intervals. This
>    reduces complexity of implementation, but takes away many possible
>    optimization for edge-cases. Alternative they propose is to use Instant.MIN
>    and Instant.MAX or similar to create unbounded-like intervals.
>
> Support for negative intervals,
>
> API supports both positive and negative and positive ranges. This is
> questionable and discussion is encouraged.
> Advantages
>
>    - Allows more flexible usage of API, which would be helpful for use
>    cases like diagrams visualization.
>
> Disadvantages
>
>    - Dramatically increases amount of boilerplate code inside the
>    implementations.
>    - Makes behaviour of potential methods like boolean endsBefore(T t) unintuitive.
>    Does this mean that end() is before that provided parameter, or latter of
>    bounds (i.e. start() for negative range and end() for positive).
>    - Limited usability scope. Most use cases would not benefit from
>    possibility of negative ranges creation, but would have to suffer
>    performance decrease.
>
> In general, either there should be support for negative ranges, or ranges
> might be end-exclusve, but not two at the same time, as having them both
> together dramatically increases complexity.
> Range is not Serializable
>
> Currently ranges are not Serializable. This is due to difficulties
> regarding using non-serializable interfaces, like ChronoDateTIme  in
> sample implementation.
> Alternatives
>
>    - Restrict range type variable to implement Serializable. I see this
>    option as undesiarable bacause of how much it narrows use of interface.
>
> Current interface methods list is minimal
>
> For now, API proposed contains minimal amount of methods that are used in
> range arithmetics. List of methods is supposed to change as discussion
> moves on.
> Generic Range class vs Rnage interface + specific inmplementations
>
> Currently, approach is to define interface and list of implementations.
> Advantages
>
>    - Ability to introduce specialized for type of range methods. For
>    example, Timespan could have Duration toDuration() method, potential
>    IntegerRange could have something like LongRange toLongRange() dur to
>    limitations of comparability between classes. This would be impossible with
>    structural class Range without declaring additional static utility methods.
>    - Enhanced validation of annotaion targets as classes, unlike
>    generics, arent erased.
>
> Disadvantages
>
>    - Increased amount of classes to maintain.
>    - Additional considerations would be required before extending Range
>    interface in case if hierarchy non-sealed to ensure backward compatibility.
>
> API DescriptionNB: Since date ranges is supposed to be one of the most
> popular if not the most popular use case for range, date-time libraries
> were main reference for interface design.
> ------------------------------
> Section: BoundsGeneral notes
>
>    - In *Boost Date_Time* (time_period.begin()), the start and end are
>    always defined, meaning there is no concept of unbounded intervals.
>    Similarly, some libraries like *Chrono* in Rust assume bounded
>    intervals by default. In fact, only a few libraries expose trully unbound
>    ranges. Although, while complexity of implementation is increased by this
>    corner cases, thier performance also vastly increased by cutting amount of
>    operations in each method at least in half (For two-way unbound interval,
>    almost all operations return constnat value).
>
> ------------------------------
> T start()
>
> *Description:*
> Returns the start of the range. If the range is unbounded at the start,
> this method throws an UnsupportedOperationException. This can be
> preemptively checked using isBoundedAtStart().
>
> *Alternatives:*
>
>    - Method could return Optional<T> instead of throwing an exception. I
>    see this two approaches roughly identical in terms of pros/cons score, so
>    suggestions are much appreciated.
>
> ------------------------------
> T end()
>
> *Description*:
> Returns the end of the range. If the range is unbounded at the end, this
> method throws an UnsupportedOperationException. Use isBoundedAtEnd() to
> check if the range is bounded.
>
> *Alternatives:*
>
>    - Simallarly to start(), method could return Optional<T> instead of
>    throwing an exception. I see this two approaches roughly identical in terms
>    of pros/cons score, so suggestions are much appreciated.
>
> ------------------------------
> boolean isBoundedAtStart()
>
> *Description*:
> Returns true if the range is bounded at the start. If unbounded, it
> returns false, meaning calling start() will throw an
> UnsupportedOperationException.
>
> *Alternatives*:
>
>    - *Joda-Time*, *NodaTime*, *Luxon*, and *Moment.js* do not explicitly
>    support unbounded intervals by default but can use null or special
>    values to represent unbounded starts.
>    - *Boost Date_Time* and *Chrono* don?t support unbounded ranges
>    directly, so this method is unnecessary.
>
> ------------------------------
> boolean isBoundedAtEnd()
>
> *Description*:
> Returns true if the range is bounded at the end. A false value means the
> range is unbounded at the end, and calling end() will throw an
> UnsupportedOperationException.
>
> *Alternatives*:
>
>    - Similar to isBoundedAtStart(), most libraries don?t have built-in
>    unbounded intervals, but the concept can be simulated using null,
>    minimal/maximal possible value etc. Pros and cons were described in API
>    notes.
>
> ------------------------------
> Section: boolean operationsboolean contains(T instant)
>
> *Description*:
> Returns true if the given instant falls within the start and end bounds
> of the range, otherwise returns false.
>
> *Similar Methods in other libraries*:
>
>    - *NodaTime (Interval.Contains)*
>    - *Joda-Time (Interval.contains)*
>    - *Luxon (Interval.contains)*
>    - *Boost Date_Time (time_period.contains())*
>    - And many others...
>
> *Differences with existing APIs*:
>
>    - *Moment.js* doesn?t provide a direct contains method but the
>    moment-range plugin adds this functionality with range.contains().
>
> *Note*: this method is present in most interval implementations.
> Terefore, I concider as basic and unremovable from the API.
> ------------------------------
> boolean overlaps(Range<? extends T> other)
>
> *Description*:
> Checks if the current range overlaps with another range. Returns true if
> the two ranges overlap, otherwise returns false.
>
> *Similar Methods in other libraries*:
>
>    - *NodaTime (Interval.Overlaps)*
>    - *Joda-Time (Interval.overlaps)*
>    - *Luxon (Interval.overlaps)*
>    - *Boost Date_Time (time_period.intersects())*
>    - And many others...
>
> *Differences with existing APIs*:
>
>    - *Moment.js*: The moment-range plugin provides a similar overlaps() method
>    to check overlap.
>    - *Chrono* relies on custom interval intersection logic.
>
> *Note*: this method is present in most interval implementations.
> Terefore, I concider as basic and unremovable from the API.
> ------------------------------
> General notes on next two methods
>
> Most of the libraries propose API like isBefore(T point) or do not
> provide methods like this at all. Since current implementation throws an
> exception if interval is not bounded, trivial check for isBefore could
> become 4-6 lines long. The question basically comes down to whether the
> Range class should be more data-structure-like or object-like. I would
> argue that at least isBefore(T moment) is required, especially since
> ranges can be negative currently. Existence of boolean isBefore(Range<?
> extends T> other)and similarisAfter` is up to discussion.
> boolean isBefore(Range<? extends T> other)
>
> *Description*:
> Returns true if the current range is strictly before another range (i.e.,
> ends before the other range starts).
>
> *Differences with other libraries*:
>
>    - *NodaTime*: You?d manually compare End of one interval with the Start of
>    another.
>    - *Joda-Time*: Manual comparison with Interval.getEnd() and
>    Interval.getStart().
>    - *Boost Date_Time* and *Chrono* would use custom logic to compare
>    time_period or ranges of time, since they don?t have a direct
>    equivalent of isBefore().
>
> *Alternatives*
>
>    - Most of the libraries propose API like isBefore(T point) or do not
>    provide methods like this at all. Since current implementation throws an
>    exception if interval is not bounded, trivial check for isBefore could
>    become 4-6 lines long. The question basically comes down to whether the
>    Range class should be more data-structure-like or object-like. I would
>    argue that at least isBefore(T moment) is required, especially since
>    ranges can be negative currently
>
> ------------------------------
> boolean isAfter(Range<? extends T> other)
>
> *Description*:
> Returns true if the current range is strictly after another range (i.e.,
> starts after the other range ends).
>
>    - *Similar Methods*:
>       - Similar to isBefore(), manual comparisons are used in *NodaTime*,
>       *Joda-Time*, and *Luxon* an others.
>
> ------------------------------
> boolean isBefore(T point)
>
> *Description:*
> Determines if the span ends before the given point. This is useful when
> you need to check whether a time span occurs entirely before a specific
> point.
>
> *Alternatives*:
>
>    - Method could be removed from APi at all, if Range is desired to be
>    skewed towards being data structure.
>
> ------------------------------
> boolean isAfter(T point)
>
> *Description:*
> Determines if the span starts after the given point. This is useful when
> you need to check whether a time span occurs entirely after a specific
> point.
>
> *Alternatives*:
>
>    - Similarly to boolean isBefore(T point), method could be removed from
>    APi at all, if Range is desired to be skewed towards being data structure.
>
> ------------------------------
> boolean isNegative()
>
> *Description*:
> Returns true if the start of the range is after the end, indicating a
> "negative" range.
>
> *Alternatives:*
>
>    - if concidered too niche, negatie timespans could be removed from
>    model.
>
> *Note:* this one is most questionable for me. Do we really need negative
> ranges? This is most entirely required in numeric ranges and diagrams,
> while introdcues huge complexity overhead for majority that doesnt need
> this feature. Negativity might be confusing for users. Would love to hear
> thoughs on this matter
> ------------------------------
> Section: Range arithmeticsOptional<Range<T>> intersection(Range<? extends
> T> other)
>
> *Description*:
> Returns the intersection of the current range with another range. If the
> ranges do not overlap, the result is an empty Optional. If they overlap,
> the intersection is returned.
>
> *Similar Methods*:
>
>    - *NodaTime (Interval.Intersection())*
>    - *Moment.js (via moment-range, range.intersect())*
>    - *Joda-Time (Interval.overlap())*
>    - And many others...
>
> *Differences with existing APIs*:
>
>    - *Boost Date_Time* returns an empty time_period if no overlap exists,
>    instead of an Optional. Some libraries return null (e.g., *NodaTime*).
>    - Other libraries return null if intervals arent overlapping. This is
>    undesrable, so optional returned instead.
>
> *Note*: this method is present in most interval implementations.
> Terefore, I concider as basic and unremovable from the API.
> ------------------------------
> Range<T>[] union(Range<? extends T> other)
>
> *Description*:
> Returns the union of two ranges. If the ranges overlap, the result is a
> single combined range. If they do not overlap, the result is an array of
> two separate ranges.
>
> *Differences with existing APIs*:
>
>    - *NodaTime* and *Joda-Time* support similar logic using custom union
>    handling.
>    - *Boost Date_Time* has no built-in union() function but you can write
>    custom logic to combine or separate intervals.
>
> *Note*: Behaviour of this method is up to change. Currently, it returns
> array for maximal performance, but it can (and most likely should) be
> wrapped in some monadic class. As an alternative, there may be support for
> non-continuous ranges (ones with gaps inside them), then this method should
> return thise kind of range.
> ------------------------------
> Optional<Range<T>> gap(Range<? extends T> other)
>
> *Description*:
> Returns the gap between two ranges, if they do not overlap. If they
> overlap, the result is an empty Optional.
>
> *Differences with existing APIs*:
>
>    - *NodaTime* and *Joda-Time* support custom logic to calculate the gap
>    using isBefore(), isAfter(), and manual calculations of the gap.
>    - Other libraries return null if intervals are overlapping. This is
>    undesrable, so optional returned instead.
>
> ------------------------------
> Section: potential methodsboolean isEmpty()
>
> *Description:*
> Determines if the range is "empty,"
>
> Empty range is its own, separate type of range (basically opposite of
> unbounded range). There are many questions regrading this type of range. Is
> it bounded at start or end? If so, what should start() or end() return.
> Them throwing an exception would violate current contract between
> IsBoundedAtX() and 'x()` methods.
>
> *Advantages*
>
>    - Returning empty range instead of Optional might be more user-friendly
>
> *Disadvantages*
>
>    - One more concept in the API model
>    - Corner case in IsBoundedAtX() and 'x()` contract.
>
> Potential Methods for API Enhancement
>
> In this section, we explore methods that could be added to the API,
> comparing them with similar functionality in popular time-related
> libraries. These methods enhance the versatility and clarity of the
> Range<T> implementation, especially in the context of temporal, numeric,
> and other domain-specific ranges. Some of these methods are inspired by
> well-established libraries, while others are novel suggestions.
> ------------------------------
> boolean encloses(Range<? extends T> other)
>
> *Description*:
> Checks whether the current range completely encloses another range, i.e.,
> the other range starts after or at the start of the current range and ends
> before or at the end of the current range.
>
>    -
>
>    *Similar Methods in Other Libraries*:
>    - *NodaTime (Interval.ContainedBy)*
>       - *Joda-Time (Interval.contains)*
>       - *Luxon (Interval.contains)*
>       - *Boost Date_Time (time_period.contains())*
>    -
>
>    *Differences with Existing APIs*:
>    - Some libraries handle encloses() and contains() in the same method.
>       For clarity, this API can separate the two, where contains() is
>       used for checking individual points and encloses() is for
>       range-level comparison.
>
> ------------------------------
> boolean abuts(Range<? extends T> other)
>
> *Description*:
> Returns true if the current range abuts (i.e., touches but does not
> overlap) with another range. This method is useful when determining whether
> two ranges are adjacent but do not overlap.
>
>    -
>
>    *Similar Methods in Other Libraries*:
>    - *NodaTime (Interval.Abuts)*
>    -
>
>    *Alternatives*:
>    - Instead of this method, users could manually compare the end of one
>       range and the start of another, but including abuts() in the API
>       simplifies the logic and reduces error-prone comparisons.
>
> ------------------------------
> Range<T> extendTo(T point)
>
> *Description*:
> Returns a new range that extends the current range to include the given
> point. If the point is already within the range, it returns the current
> range. Otherwise, it extends either the start or end, depending on the
> point's position relative to the range.
>
>    -
>
>    *Similar Methods in Other Libraries*:
>    - *NodaTime* and *Joda-Time* do not have explicit methods for this,
>       but users can manipulate intervals manually.
>       - *Moment.js*: The moment-ran
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/6c8fe715/attachment-0001.htm>

From dholmes at openjdk.org  Mon Sep 23 01:57:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 01:57:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <I-UJVlTAQwhlE4nXETiFJibY0F3-SwWBzXg4QJW5WQs=.3a4edd35-7948-4098-9004-d281874f0733@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <I-UJVlTAQwhlE4nXETiFJibY0F3-SwWBzXg4QJW5WQs=.3a4edd35-7948-4098-9004-d281874f0733@github.com>
Message-ID: <2h62aBjd7P_v2kWBqT3cVSQN6HjDCRlh4Wtp6l2kp9s=.3a9ed65d-5707-4c33-8f51-1a2586357da1@github.com>

On Fri, 20 Sep 2024 08:48:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Just be clarify: is it your expectation that, in order for this issue to be fixed, we should fix the javadoc of all caller sensitive methods, addressing issues that have nothing to do with restricted-ness?

No, just the new restricted methods. The doc for other context-sensitive methods may be lacking but that is a separate issue. I don't know what @jddarcy had in mind.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2367107782

From archie.cobbs at gmail.com  Mon Sep 23 02:10:29 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 22 Sep 2024 21:10:29 -0500
Subject: Range API
In-Reply-To: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
Message-ID: <CANSoFxtRywZSQtd+ACkUoHDvwTo6Ls851pn1zr0oKNBXQ-tDpw@mail.gmail.com>

On Sun, Sep 22, 2024 at 2:03?PM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> Hello everyone! I am writing here today to invite everyone to participate
> in the discussion regarding the Range APi proposal I have made into JDK.
>

A few comments...

Guava has addressed this same problem; their approach worth reviewing:
https://github.com/google/guava/wiki/RangesExplained

You are restricting to domains that implement Comparable, but this limits
usefulness. For example, byte[] arrays are often ordered lexicographically
as unsigned values and we want to work with ranges of byte[] arrays. It
would be more general to allow supplying a Comparator (if needed, otherwise
null). Then you would also want to expose this using a comparator() method
(like SortedSet does). Note that Guava does not allow providing a
Comparator so they voted the other way on this.

The start() and end() be should be specifiable as either inclusive or
exclusive, otherwise open bounds are not possible. For example, how would
one express the range of all Strings strictly less than "zzz"? (note every
element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
"zzz"). This is why for example NavigableSet.subSet() has parameters for
that.

I've never encountered a negative range and am skeptical that it would
actually be useful. What's an example of a real-world use case? I don't see
how they would help diagrams visualization other than maybe saving you a
boolean, i.e., you could just use the normal range and draw the arrow the
other way.

In my experience, when you work with ranges you often also need to work
with sets of ranges. If we had a Range class then it would be natural to
also have a RangeSet class as well with union, intersection, difference,
and ordered iteration operations, etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/35e2733c/attachment.htm>

From liach at openjdk.org  Mon Sep 23 02:14:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 02:14:20 GMT
Subject: RFR: 8340587: Optimize StackMapGenerator$Frame::checkAssignableTo
In-Reply-To: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
References: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
Message-ID: <4ftXzNjPQzV7xPDWM9Q3sMutl2HDpXdAKavVZHPJRhw=.31771ee5-0ae7-4325-a077-757170b33ba6@github.com>

On Sun, 22 Sep 2024 13:20:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone instead of Array.copyOf to avoid compression and then expansion

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1102:

> 1100:                 target.localsSize = localsSize;
> 1101:                 if (stackSize > 0) {
> 1102:                     target.stack = Arrays.copyOf(stack, stackSize);

Do you think we should use `.clone()` to avoid `getClass` checks and to avoid extra array growing in case the new stack/local immediately grows due to instructions after target?

Also I think you can do `localsSize > 0` check for locals assignment too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21121#discussion_r1770557300

From swen at openjdk.org  Mon Sep 23 02:14:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 02:14:20 GMT
Subject: RFR: 8340587: Optimize StackMapGenerator$Frame::checkAssignableTo
In-Reply-To: <4ftXzNjPQzV7xPDWM9Q3sMutl2HDpXdAKavVZHPJRhw=.31771ee5-0ae7-4325-a077-757170b33ba6@github.com>
References: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
 <4ftXzNjPQzV7xPDWM9Q3sMutl2HDpXdAKavVZHPJRhw=.31771ee5-0ae7-4325-a077-757170b33ba6@github.com>
Message-ID: <7l5T_qNjYDsVhZdDTtH11j3gewswR9rX-1ZLW88pkWM=.a1fe2e05-5a57-42ee-82da-f5193eedb893@github.com>

On Sun, 22 Sep 2024 13:37:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone instead of Array.copyOf to avoid compression and then expansion
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1102:
> 
>> 1100:                 target.localsSize = localsSize;
>> 1101:                 if (stackSize > 0) {
>> 1102:                     target.stack = Arrays.copyOf(stack, stackSize);
> 
> Do you think we should use `.clone()` to avoid `getClass` checks and to avoid extra array growing in case the new stack/local immediately grows due to instructions after target?
> 
> Also I think you can do `localsSize > 0` check for locals assignment too.

stack.length may be larger than stackSize. In this case, the length of the array copied by clone will be longer than Arrays.copyOf. However, I have no evidence that Arrays.copyOf is faster than clone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21121#discussion_r1770563199

From swen at openjdk.org  Mon Sep 23 02:14:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 02:14:20 GMT
Subject: RFR: 8340587: Optimize StackMapGenerator$Frame::checkAssignableTo
In-Reply-To: <7l5T_qNjYDsVhZdDTtH11j3gewswR9rX-1ZLW88pkWM=.a1fe2e05-5a57-42ee-82da-f5193eedb893@github.com>
References: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
 <4ftXzNjPQzV7xPDWM9Q3sMutl2HDpXdAKavVZHPJRhw=.31771ee5-0ae7-4325-a077-757170b33ba6@github.com>
 <7l5T_qNjYDsVhZdDTtH11j3gewswR9rX-1ZLW88pkWM=.a1fe2e05-5a57-42ee-82da-f5193eedb893@github.com>
Message-ID: <KbJGAzZTyqvgGUuwoH3Ox1v--Vfia2BbPxSvm9FVXzI=.5a61d74d-1562-414a-8994-0c07575b64e4@github.com>

On Sun, 22 Sep 2024 14:08:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1102:
>> 
>>> 1100:                 target.localsSize = localsSize;
>>> 1101:                 if (stackSize > 0) {
>>> 1102:                     target.stack = Arrays.copyOf(stack, stackSize);
>> 
>> Do you think we should use `.clone()` to avoid `getClass` checks and to avoid extra array growing in case the new stack/local immediately grows due to instructions after target?
>> 
>> Also I think you can do `localsSize > 0` check for locals assignment too.
>
> stack.length may be larger than stackSize. In this case, the length of the array copied by clone will be longer than Arrays.copyOf. However, I have no evidence that Arrays.copyOf is faster than clone.

I found through debugging that in the `target.flags == -1` branch of checkAssignableTo, `localsSize > 0 and stackSize = 0` are always, so I made this optimization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21121#discussion_r1770564307

From liach at openjdk.org  Mon Sep 23 02:14:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 02:14:21 GMT
Subject: RFR: 8340587: Optimize StackMapGenerator$Frame::checkAssignableTo
In-Reply-To: <KbJGAzZTyqvgGUuwoH3Ox1v--Vfia2BbPxSvm9FVXzI=.5a61d74d-1562-414a-8994-0c07575b64e4@github.com>
References: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
 <4ftXzNjPQzV7xPDWM9Q3sMutl2HDpXdAKavVZHPJRhw=.31771ee5-0ae7-4325-a077-757170b33ba6@github.com>
 <7l5T_qNjYDsVhZdDTtH11j3gewswR9rX-1ZLW88pkWM=.a1fe2e05-5a57-42ee-82da-f5193eedb893@github.com>
 <KbJGAzZTyqvgGUuwoH3Ox1v--Vfia2BbPxSvm9FVXzI=.5a61d74d-1562-414a-8994-0c07575b64e4@github.com>
Message-ID: <KCOnkf_FAhdBRIvr2NN_mRGQmNuzdo1TlwPe2WpNrg0=.503a835c-a0fc-4714-923f-9f2eea32ce56@github.com>

On Sun, 22 Sep 2024 14:14:11 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> stack.length may be larger than stackSize. In this case, the length of the array copied by clone will be longer than Arrays.copyOf. However, I have no evidence that Arrays.copyOf is faster than clone.
>
> I found through debugging that in the `target.flags == -1` branch of checkAssignableTo, `localsSize > 0 and stackSize = 0` are always, so I made this optimization.

`stackSize` always has to be less than or equal to `stack.length`; this is just like `ArrayList`, where `stackSize` is the size and `stack.length` is capacity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21121#discussion_r1770565183

From swen at openjdk.org  Mon Sep 23 02:14:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 02:14:20 GMT
Subject: RFR: 8340587: Optimize StackMapGenerator$Frame::checkAssignableTo
Message-ID: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>

Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone instead of Array.copyOf to avoid compression and then expansion

-------------

Commit messages:
 - suggestion from @liach
 - optimize checkAssignableTo

Changes: https://git.openjdk.org/jdk/pull/21121/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340587
  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21121/head:pull/21121

PR: https://git.openjdk.org/jdk/pull/21121

From dholmes at openjdk.org  Mon Sep 23 02:24:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 02:24:37 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <NL8iG2azJHyM4EUUl_U2fTOcBdL-_9CrudqwQWJXBxY=.50f53e6a-cbe6-4b7b-bd38-d5a2fabc5f90@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

Looks fine. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21082#pullrequestreview-2321044142

From henryjen at openjdk.org  Mon Sep 23 03:18:35 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Sep 2024 03:18:35 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <VKX75rncoroJM39Ind0XKdfIQ-pibmkYnlLX6wICnuQ=.f9a36e03-3f9e-42cc-a19f-177952b2e746@github.com>

On Mon, 16 Sep 2024 17:50:52 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
> 
> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
> 
> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
> 
> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
> 
> So we make this build in advance, and use a static array for values referred more than once.
> 
> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.

Absolutely, updated the description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21022#issuecomment-2367161927

From jpai at openjdk.org  Mon Sep 23 04:33:50 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Sep 2024 04:33:50 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v8]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <NxoFCS8fIKiHrwB-eHLlMMCJBTzFJOytEiNdWv6CmaU=.82420a2d-807a-41ee-91e4-1fefbe767b99@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - move the code comment to a function comment
 - clarify who sets the _JAVA_VERSION_SET environment variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/04bf9f4a..80d8a153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=06-07

  Stats: 19 lines in 2 files changed: 9 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From jpai at openjdk.org  Mon Sep 23 04:33:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Sep 2024 04:33:51 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v7]
In-Reply-To: <GCp9gNTM9xul6GvcQergh7Y5H9MpoaJeVT7rOQdips4=.19b05d45-dade-422c-b297-9a09651dba2d@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <Lq3gAniqEIGw-bFsz5CjiQF7D6vk-xdR6C6kZB424bA=.bff112da-f7a7-484b-b349-29d3b8aa1d7e@github.com>
 <GCp9gNTM9xul6GvcQergh7Y5H9MpoaJeVT7rOQdips4=.19b05d45-dade-422c-b297-9a09651dba2d@github.com>
Message-ID: <_FCvQkd6jowbev2dON9PgubcqFqG5eBOBzfh2ZXmDPw=.3da680d6-3a5b-4714-9892-f602e02078cd@github.com>

On Sun, 22 Sep 2024 15:00:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   treat -version: -jre-restrict-search and -jre-no-restrict-search like any other unknown option
>
> src/java.base/share/native/libjli/java.c line 1401:
> 
>> 1399: SetupSplashScreenEnvVars(const char *splash_file_path, // "-splash:" option value (may be NULL)
>> 1400:                          char *jar_path // the jar file being launched (may be NULL)
>> 1401: ) {
> 
> I think this would be a bit cleaner if you put comment on the function to document the two args. That would remove the // comments that make this hard to read right now.

Done, I've now moved those comments as function documentation.

> src/java.base/share/native/libjli/java.h line 58:
> 
>> 56:  * java runtime (older, newer or same version JRE installed at a different location) than
>> 57:  * the one the launcher belongs to.
>> 58:  * That support was discontinued starting Java 9. However, java launcher in JDK 1.8 can still
> 
> I assume this should say "JDK 9" rather than "Java 9".
> 
> I read this paragraph a few times and one thing that I don't think is made clear is that it's the JDK 8 launcher that is exec'ing the JDK N launcher with the env variable set. Instead it speaks of launching the "higher version java runtimes". At some point we are going to have to fix an exit route. In the mean-time, anyone touching this code will read this and it may not be clear how the JDK N launcher gets exec'ed with this env variable set.

Hello Alan, I've updated the PR to clarify this part of the comment. Let me know if the latest version reads better.

> At some point we are going to have to fix an exit route.

I suspect that exit route would have to come as a CSR in Java 8 to discontinue support for launching Java runtimes  greater than Java 23 (for example), through the mJRE selection mechanism.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770761203
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770760965

From jpai at openjdk.org  Mon Sep 23 04:46:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Sep 2024 04:46:35 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <mwyaxktWjoPoB5klx6cturILOndu_0usfw_HM0VbOuo=.8625d290-acc4-468d-83c9-68f7da1ba06b@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
 <mwyaxktWjoPoB5klx6cturILOndu_0usfw_HM0VbOuo=.8625d290-acc4-468d-83c9-68f7da1ba06b@github.com>
Message-ID: <k0sD6JecW_qNVBQ3xN6vrd9iEQpnN4lF71S8sDvdu40=.efbb7afe-95b8-4d4d-a8a7-d0868b1072e4@github.com>

On Sun, 22 Sep 2024 12:48:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Matthias, please give me a day or two to run this against our internal CI to make sure there are no unexpected issues.

tier1, tier2, tier3 testing in our CI has completed successfully, so this looks OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21082#issuecomment-2367228606

From dholmes at openjdk.org  Mon Sep 23 04:46:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 04:46:38 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v8]
In-Reply-To: <NxoFCS8fIKiHrwB-eHLlMMCJBTzFJOytEiNdWv6CmaU=.82420a2d-807a-41ee-91e4-1fefbe767b99@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <NxoFCS8fIKiHrwB-eHLlMMCJBTzFJOytEiNdWv6CmaU=.82420a2d-807a-41ee-91e4-1fefbe767b99@github.com>
Message-ID: <ivoPletwkl_1EB4BpVJr3qJvMVp6T0IMTFil2PEfMzY=.6e1bb1ac-1e11-4607-adee-d7b584c1bec8@github.com>

On Mon, 23 Sep 2024 04:33:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move the code comment to a function comment
>  - clarify who sets the _JAVA_VERSION_SET environment variable

src/java.base/share/native/libjli/java.c line 1405:

> 1403:  * when launching java. It may be null, which implies the "-splash:" option wasn't used.
> 1404:  * The jar_path is the value that was provided to the "-jar" option when launching java.
> 1405:  * It too may be null, which implies the "-jar" option wasn't used.

But presumably we only call this function if (at least?) one of them is not null?

src/java.base/share/native/libjli/java.h line 58:

> 56:  * java runtime (older, newer or same version JRE installed at a different location) than
> 57:  * the one the launcher belongs to.
> 58:  * That support was discontinued starting JDK 9. However, JDK 1.8 launcher can still

Suggestion:

 * That support was discontinued starting JDK 9. However, the JDK 8 launcher can still

src/java.base/share/native/libjli/java.h line 59:

> 57:  * the one the launcher belongs to.
> 58:  * That support was discontinued starting JDK 9. However, JDK 1.8 launcher can still
> 59:  * be launched with JRE version selection options to launch Java runtimes greater than Java 8.

Suggestion:

 * be started with JRE version selection options to launch Java runtimes greater than JDK 8.

src/java.base/share/native/libjli/java.h line 60:

> 58:  * That support was discontinued starting JDK 9. However, JDK 1.8 launcher can still
> 59:  * be launched with JRE version selection options to launch Java runtimes greater than Java 8.
> 60:  * In such cases, the JDK 1.8 launcher when exec()ing the JDK N launcher, will set and propagate

Suggestion:

 * In such cases, the JDK 8 launcher when exec()ing the JDK N launcher, will set and propagate

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770764935
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770765330
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770765205
PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770765735

From jpai at openjdk.org  Mon Sep 23 04:53:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Sep 2024 04:53:15 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v9]
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - David's review for code comment
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - David's review for code comment
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - David's review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20997/files
  - new: https://git.openjdk.org/jdk/pull/20997/files/80d8a153..7b7377cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20997&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20997/head:pull/20997

PR: https://git.openjdk.org/jdk/pull/20997

From jpai at openjdk.org  Mon Sep 23 04:53:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Sep 2024 04:53:15 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v8]
In-Reply-To: <ivoPletwkl_1EB4BpVJr3qJvMVp6T0IMTFil2PEfMzY=.6e1bb1ac-1e11-4607-adee-d7b584c1bec8@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <NxoFCS8fIKiHrwB-eHLlMMCJBTzFJOytEiNdWv6CmaU=.82420a2d-807a-41ee-91e4-1fefbe767b99@github.com>
 <ivoPletwkl_1EB4BpVJr3qJvMVp6T0IMTFil2PEfMzY=.6e1bb1ac-1e11-4607-adee-d7b584c1bec8@github.com>
Message-ID: <dhWcDVS4CEuzPeA5-L20dBk2lxzlStaTYU48O_Ryj88=.33e07589-8192-45f9-beb8-2963eb3e583e@github.com>

On Mon, 23 Sep 2024 04:41:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move the code comment to a function comment
>>  - clarify who sets the _JAVA_VERSION_SET environment variable
>
> src/java.base/share/native/libjli/java.c line 1405:
> 
>> 1403:  * when launching java. It may be null, which implies the "-splash:" option wasn't used.
>> 1404:  * The jar_path is the value that was provided to the "-jar" option when launching java.
>> 1405:  * It too may be null, which implies the "-jar" option wasn't used.
> 
> But presumably we only call this function if (at least?) one of them is not null?

Hello David, the implementation of this function takes the responsibility of acting as a no-op if both the parameters are null. The call site doesn't do that check. Do you prefer the call site to do that check and we update this function's documentation that at least one of them should be non null?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770767593

From dholmes at openjdk.org  Mon Sep 23 05:12:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 05:12:36 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v9]
In-Reply-To: <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>
Message-ID: <-buRdN121mrSZUcWm0PVNulRrEgZUJTLt3gv7BkPHHM=.130125a7-45a8-4d59-9260-6443bc6f4f2e@github.com>

On Mon, 23 Sep 2024 04:53:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - David's review for code comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - David's review for code comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - David's review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

LGTM

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20997#pullrequestreview-2321138391

From dholmes at openjdk.org  Mon Sep 23 05:12:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 05:12:36 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v8]
In-Reply-To: <dhWcDVS4CEuzPeA5-L20dBk2lxzlStaTYU48O_Ryj88=.33e07589-8192-45f9-beb8-2963eb3e583e@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <NxoFCS8fIKiHrwB-eHLlMMCJBTzFJOytEiNdWv6CmaU=.82420a2d-807a-41ee-91e4-1fefbe767b99@github.com>
 <ivoPletwkl_1EB4BpVJr3qJvMVp6T0IMTFil2PEfMzY=.6e1bb1ac-1e11-4607-adee-d7b584c1bec8@github.com>
 <dhWcDVS4CEuzPeA5-L20dBk2lxzlStaTYU48O_Ryj88=.33e07589-8192-45f9-beb8-2963eb3e583e@github.com>
Message-ID: <muFGyNvBnd8O_DAW9klHshuAjiZcCCHwEkSvsITgCmQ=.c1320908-9986-4d4a-99b8-9b8f95715b42@github.com>

On Mon, 23 Sep 2024 04:47:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1405:
>> 
>>> 1403:  * when launching java. It may be null, which implies the "-splash:" option wasn't used.
>>> 1404:  * The jar_path is the value that was provided to the "-jar" option when launching java.
>>> 1405:  * It too may be null, which implies the "-jar" option wasn't used.
>> 
>> But presumably we only call this function if (at least?) one of them is not null?
>
> Hello David, the implementation of this function takes the responsibility of acting as a no-op if both the parameters are null. The call site doesn't do that check. Do you prefer the call site to do that check and we update this function's documentation that at least one of them should be non null?

No, no, that is fine as-is. I was mis-remembering how the code was structured.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1770776945

From jpai at openjdk.org  Mon Sep 23 05:16:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Sep 2024 05:16:52 GMT
Subject: RFR: 8340596: Remove dead code from RequiresSetenv function in
 java.base/unix/native/libjli/java_md.c
Message-ID: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>

Can I please get a review of this trivial change which removes dead code from the `RequiresSetenv()` function?

As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a left-over from the changes in https://bugs.openjdk.org/browse/JDK-8244224.

No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

-------------

Commit messages:
 - 8340596: Remove dead code from RequiresSetenv function in java.base/unix/native/libjli/java_md.c

Changes: https://git.openjdk.org/jdk/pull/21125/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340596
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21125/head:pull/21125

PR: https://git.openjdk.org/jdk/pull/21125

From swen at openjdk.org  Mon Sep 23 05:34:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 05:34:10 GMT
Subject: RFR: 8337279: Optimize format instant [v8]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <MlAgMp2zfrel1nbhLyon1wufdZ5DgWV37u0DKBaio8M=.c946f032-5e3d-4bed-a569-59c6a6aa0056@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:

  suggestion from @jensli

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/df2a13d4..2342276e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=06-07

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 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 Sep 23 05:37:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 05:37:17 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: <HkP-NaJux3FUlRBC5SBu6rSwtFwkxMv0dXInEzRAKc4=.9b397c8e-ad0d-450a-b77d-ad77ada4cc85@github.com>

On Tue, 3 Sep 2024 17:32:43 GMT, Naoto Sato <naoto 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>
> ```

If SharedSecret is not recommended, do you recommend extracting these methods to jdk.internal?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2367270116

From swen at openjdk.org  Mon Sep 23 05:37:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 05:37:17 GMT
Subject: RFR: 8337279: Optimize format instant [v9]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <qDZYwduDAsDHQ6uayxtWY_t6SIsKT5uNBrmWWCmtb9M=.7c22d0fa-8153-4224-9a0c-c5d2994b598b@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 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:

 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
 - suggestion from @jensli
 - 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
 - ... and 1 more: https://git.openjdk.org/jdk/compare/32c9de0b...1c2482e7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/2342276e..1c2482e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=07-08

  Stats: 179340 lines in 1462 files changed: 162395 ins; 8883 del; 8062 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 ccheung at openjdk.org  Mon Sep 23 05:59:38 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 23 Sep 2024 05:59:38 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <7x-dr_M70dbSsP6Jr-QIY1g40vSdKMnXmkwfuUElzDg=.ca786a00-1613-4db3-a53b-0ce01942e5bd@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
 <7x-dr_M70dbSsP6Jr-QIY1g40vSdKMnXmkwfuUElzDg=.ca786a00-1613-4db3-a53b-0ce01942e5bd@github.com>
Message-ID: <ubDPqGHy-8mHVHBksyOMaZkRtdpJAlddvpYX8ykDSVY=.1b0b6255-eff6-4f00-9efa-e1734d46e618@github.com>

On Sat, 21 Sep 2024 06:31:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trailing whitespace
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferences.java line 105:
> 
>> 103:             public byte[] generate(String algorithm) {
>> 104:               return ModuleHashes.computeHash(supplier, algorithm);
>> 105:             }
> 
> Why is JarModuleReader changed to use a file string, is this because of an environment dependency when using a Path?

It is to avoid the following warnings during dump time:

[1.607s][warning][cds,heap  ] Archive heap points to a static field that may be reinitialized at runtime:
[1.607s][warning][cds,heap  ] Field: java/util/zip/ZipFile$Source::builtInFS
[1.607s][warning][cds,heap  ] Value: sun.nio.fs.LinuxFileSystem
...
[1.607s][warning][cds,heap  ] Archive heap points to a static field that may be reinitialized at runtime:
[1.607s][warning][cds,heap  ] Field: sun/nio/fs/DefaultFileSystemProvider::INSTANCE
[1.607s][warning][cds,heap  ] Value: sun.nio.fs.LinuxFileSystemProvider

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1770803768

From dholmes at openjdk.org  Mon Sep 23 06:38:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 06:38:35 GMT
Subject: RFR: 8340596: Remove dead code from RequiresSetenv function in
 java.base/unix/native/libjli/java_md.c
In-Reply-To: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>
References: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>
Message-ID: <HSAljogPu2pRw0--UblZNrlC2n1IkmuWwRCbGdaqQCY=.cc1f027f-f13c-48fe-b93a-4821875a1038@github.com>

On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which removes dead code from the `RequiresSetenv()` function?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a left-over from the changes in https://bugs.openjdk.org/browse/JDK-8244224.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

Looks good and trivial.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21125#pullrequestreview-2321225955

From mbaesken at openjdk.org  Mon Sep 23 06:43:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 23 Sep 2024 06:43:41 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <o2yX16JXsezlSbrp3cYK-8Rs7zAe5zWUex8oviqlB0s=.19169a03-2814-4ff3-b5aa-615d00646e13@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21082#issuecomment-2367340359

From mbaesken at openjdk.org  Mon Sep 23 06:43:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 23 Sep 2024 06:43:42 GMT
Subject: Integrated: 8340387: Update OS detection code to recognize Windows
 Server 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <0Z9ZuNKtNNvjwydeRBf-E1-Vs6eh29FAsP1i0KxklsY=.57b7fe50-6805-47ec-af74-a10643b89bff@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

This pull request has now been integrated.

Changeset: 34cddfbe
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34cddfbedd20d5804cab8044fbc402564e98eb9c
Stats:     11 lines in 2 files changed: 8 ins; 0 del; 3 mod

8340387: Update OS detection code to recognize Windows Server 2025

Reviewed-by: mdoerr, jwaters, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/21082

From mbaesken at openjdk.org  Mon Sep 23 08:12:05 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 23 Sep 2024 08:12:05 GMT
Subject: RFR: 8340623: remove outdated PROCESSOR_ARCHITECTURE_IA64 from Windows
 coding
Message-ID: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>

We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any more for a very long time in OpenJDK.

-------------

Commit messages:
 - JDK-8340623

Changes: https://git.openjdk.org/jdk/pull/21130/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340623
  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21130/head:pull/21130

PR: https://git.openjdk.org/jdk/pull/21130

From alanb at openjdk.org  Mon Sep 23 08:20:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 08:20:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v2]
In-Reply-To: <tY1gKsqmnCiAvyhg-3gwZU7dRIKwlManOpqqqCdCBx8=.91109f12-2bf7-4c75-b8ce-939a56b6578f@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <ZSYSbA1fue8QaqzsttjmTsDf_5873nMoVj6NeQ1YHkU=.4ca28e60-48b9-4d0e-b61b-1f11892a5b69@github.com>
 <tY1gKsqmnCiAvyhg-3gwZU7dRIKwlManOpqqqCdCBx8=.91109f12-2bf7-4c75-b8ce-939a56b6578f@github.com>
Message-ID: <909xd2itFsCe5aMkVmzEfLnR68_UrxakaSGDWZMdqXU=.d585d3ee-8cac-4365-ae90-d4553e94211f@github.com>

On Thu, 19 Sep 2024 14:08:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move restricted method page to `java.lang`
>>   Update restricted method page
>
> src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 41:
> 
>> 39:     done either via implementation-specific command line options or programmatically, e.g.
>> 40:     by calling <a href="../../ModuleLayer.Controller.html#enableNativeAccess(java.lang.Module)"><code>ModuleLayer.Controller.enableNativeAccess(java.lang.Module)</code></a>.</p>
>> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,
> 
> IMHO, having this text here is better than copy and paste a similar version of this text in 14 (!!) places. That's why we added the `@Restricted` annotation, to make sure that uniform javadoc is generated for all restricted methods.

At some point we may have to re-visit the word "access". All restricted methods are accessible (public methods in  public classes in exported packages) as need to more clearly distinguish this from the native or restricted operation the method performs.  Okay for now as this PR is mostly moving text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1770954535

From alanb at openjdk.org  Mon Sep 23 08:25:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 08:25:36 GMT
Subject: RFR: 8340623: remove outdated PROCESSOR_ARCHITECTURE_IA64 from
 Windows coding
In-Reply-To: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
References: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
Message-ID: <KCwAilzild8MHHPQ3QS8eYpyOIMZ9xSg4zMSwhM_m88=.e6f189c0-3260-444a-b01e-be04393796ac@github.com>

On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any more for a very long time in OpenJDK.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21130#pullrequestreview-2321461289

From alanb at openjdk.org  Mon Sep 23 08:25:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 08:25:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
Message-ID: <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>

On Thu, 19 Sep 2024 21:25:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 43:

> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,
> 42:     or from an <a href="../Linker.html#upcallStub(java.lang.invoke.MethodHandle,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Arena,java.lang.foreign.Linker.Option...)">upcall stub</a>
> 43:     and a Java caller can not be determined, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>

Is there any scenario where there are Java frames on the stack but calling through a native frame and back to Java with an upcall leads to the "can not be determined". I can't think of any so wonder if this can be changed to say "no caller class on the stack" as is done in the several CS methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1770962274

From alanb at openjdk.org  Mon Sep 23 08:45:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 08:45:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <3Nt65-I0eETs2YZZ3Pr3Tq6NmPSYCnmXdNONuuht9Xw=.2dbb43c3-a26d-445b-a50d-b2e798d22454@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <XH6kvzP6J5_bzVziFnygM0mV8gc4M9WP9yc4VOT5H1E=.6c72b5fc-2bcb-44f4-b6b5-05a24a7c933d@github.com>
 <3Nt65-I0eETs2YZZ3Pr3Tq6NmPSYCnmXdNONuuht9Xw=.2dbb43c3-a26d-445b-a50d-b2e798d22454@github.com>
Message-ID: <I5EBzFaanQfWonVn4vFYOeTsLfjPlGididkQwwuQMy8=.ca5bf010-d1da-4e41-afdc-7386e3b7819c@github.com>

On Thu, 19 Sep 2024 12:29:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As I wrote in the CSR request for the JEP:
> 
> > I think each method that is restricted and/or caller-sensitive should specify what happens when called when there is no caller context. We should use `AccessibleObject::canAccess` as an exemplar here:
> > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/reflect/AccessibleObject.html#canAccess(java.lang.Object)
> > I have no doubt other caller-sensitive methods have failed to do this to date, but that should be fixed.
> 
> This has to be mentioned in e.g. the javadoc for `System.loadLibrary`.

The changes in this PR means that the javadoc generated text "XXX is a restricted method of the Java platform" now links to the restricted method page. That page specifies that calling the method without a caller class will be treated as if called from code in an unnamed module.  Is your ask that the javadoc generated text inline this, or the equivalent by change the method description of each restricted method? I don't think this is critical for this this PR, and arguably a corner case to be upcalling from JNI attached threads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2367573567

From jvernee at openjdk.org  Mon Sep 23 09:25:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 09:25:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
Message-ID: <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>

On Mon, 23 Sep 2024 08:22:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
>>   
>>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 43:
> 
>> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,
>> 42:     or from an <a href="../Linker.html#upcallStub(java.lang.invoke.MethodHandle,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Arena,java.lang.foreign.Linker.Option...)">upcall stub</a>
>> 43:     and a Java caller can not be determined, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>
> 
> Is there any scenario where there are Java frames on the stack but calling through a native frame and back to Java with an upcall leads to the "can not be determined". I can't think of any so wonder if this can be changed to say "no caller class on the stack" as is done in the several CS methods.

I suggested the current wording here: https://github.com/openjdk/jdk/pull/21067#discussion_r1767316787

I think 'no caller on the stack' is too vague. AFAICT, the mechanism by which a CS method determines its caller is not documented (if it is, we should link to that here). Also, I think a user might reasonably ask: "In which cases would there not be a caller class on the stack?". So, I suggested the blanket statement instead, rather than leaning on poorly defined concepts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1771041947

From pminborg at openjdk.org  Mon Sep 23 09:32:53 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 09:32:53 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v2]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <6RBHENTj0cDdOdG5LdZ6kpFk6Uf0M0KvuIuYsvMQq6Y=.04647318-9859-4e6a-ac28-f3811619bb52@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Check exception message
 - Remove redundant doc section

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/c1d3b655..d0575fd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=00-01

  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From dholmes at openjdk.org  Mon Sep 23 09:34:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 09:34:40 GMT
Subject: RFR: 8340623: remove outdated PROCESSOR_ARCHITECTURE_IA64 from
 Windows coding
In-Reply-To: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
References: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
Message-ID: <c92Wa4D-tQXMfT7gxQD6WvM0EdKyG-j0WxSEfyoeSxo=.d0db3429-11d8-404b-885b-5bc1219efa11@github.com>

On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any more for a very long time in OpenJDK.

Seems fine.

I thought we had eradicated ia64 from the codebase but it seems we missed a few things in hotspot too. :( I will file an issue to clean that up ...

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21130#pullrequestreview-2321618174

From alanb at openjdk.org  Mon Sep 23 09:35:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 09:35:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
Message-ID: <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>

On Mon, 23 Sep 2024 09:21:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 43:
>> 
>>> 41: <p>When a restricted method is invoked by <a href="../../../../specs/jni/index.html">JNI code</a>,
>>> 42:     or from an <a href="../Linker.html#upcallStub(java.lang.invoke.MethodHandle,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Arena,java.lang.foreign.Linker.Option...)">upcall stub</a>
>>> 43:     and a Java caller can not be determined, it is as if the restricted method call occurred in an <em>unnamed module</em>.</p>
>> 
>> Is there any scenario where there are Java frames on the stack but calling through a native frame and back to Java with an upcall leads to the "can not be determined". I can't think of any so wonder if this can be changed to say "no caller class on the stack" as is done in the several CS methods.
>
> I suggested the current wording here: https://github.com/openjdk/jdk/pull/21067#discussion_r1767316787
> 
> I think 'no caller on the stack' is too vague. AFAICT, the mechanism by which a CS method determines its caller is not documented (if it is, we should link to that here). Also, I think a user might reasonably ask: "In which cases would there not be a caller class on the stack?". So, I suggested the blanket statement instead, rather than leaning on poorly defined concepts.

We use "no caller class" in the CS methods, maybe it could be improved. 

I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1771061309

From dholmes at openjdk.org  Mon Sep 23 09:41:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 09:41:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
Message-ID: <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>

On Mon, 23 Sep 2024 09:33:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I suggested the current wording here: https://github.com/openjdk/jdk/pull/21067#discussion_r1767316787
>> 
>> I think 'no caller on the stack' is too vague. AFAICT, the mechanism by which a CS method determines its caller is not documented (if it is, we should link to that here). Also, I think a user might reasonably ask: "In which cases would there not be a caller class on the stack?". So, I suggested the blanket statement instead, rather than leaning on poorly defined concepts.
>
> We use "no caller class" in the CS methods, maybe it could be improved. 
> 
> I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.

It is documented by the CS JEP: https://openjdk.org/jeps/176

> It discovers its caller's class by invoking the sun.reflect.Reflection.getCallerClass method.

CS set the precedent here and the terminology.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1771071523

From dholmes at openjdk.org  Mon Sep 23 09:49:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Sep 2024 09:49:37 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <I5EBzFaanQfWonVn4vFYOeTsLfjPlGididkQwwuQMy8=.ca5bf010-d1da-4e41-afdc-7386e3b7819c@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <XH6kvzP6J5_bzVziFnygM0mV8gc4M9WP9yc4VOT5H1E=.6c72b5fc-2bcb-44f4-b6b5-05a24a7c933d@github.com>
 <3Nt65-I0eETs2YZZ3Pr3Tq6NmPSYCnmXdNONuuht9Xw=.2dbb43c3-a26d-445b-a50d-b2e798d22454@github.com>
 <I5EBzFaanQfWonVn4vFYOeTsLfjPlGididkQwwuQMy8=.ca5bf010-d1da-4e41-afdc-7386e3b7819c@github.com>
Message-ID: <c9rLxVEJcqZii0PIflV6ZH9Vl0VWgO2yRxppyzXs-9M=.dfbefa19-8b6e-4a6c-a265-824ad1c3a5b5@github.com>

On Mon, 23 Sep 2024 08:42:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is your ask that the javadoc generated text inline this, or the equivalent by change the method description of each restricted method? 

I admit I had missed the fact there would be some auto-generated text and links in the API docs for `System.loadLibrary`, as I've stated before I was basing this on how CS is handled in specific CS methods. A prominent link to the "restricted method" text may suffice, though at the moment the restricted method text doesn't seem to talk about simple native method calls at all, so the reason for `loadLibrary` being restricted is not at all obvious IMO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2367720802

From redestad at openjdk.org  Mon Sep 23 09:50:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Sep 2024 09:50:05 GMT
Subject: RFR: 8340571: Outline code from the loop in ZipFile.Source.initCen
Message-ID: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>

This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic as possible into the per-entry method processor. This inner method will be called often and JIT optimized earlier in the bootstrap sequence.

Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both my M1 macbook and my x64 wokstation, while we also improve on relevant throughput microbenchmarks:


Name               (size) Cnt       Base      Error        Test      Error  Unit  Change
openCloseZipFile      512  15  61372.449 ? 1197.432   58081.423 ? 1751.988 ns/op   1.06x (p = 0.000*)
openCloseZipFile     1024  15 117953.727 ? 3202.274  112548.875 ? 5126.665 ns/op   1.05x (p = 0.001*)
openCloseZipFilex2    512  15  62141.795 ?  674.121   60520.017 ? 2438.346 ns/op   1.03x (p = 0.017 )
openCloseZipFilex2   1024  15 117959.071 ? 1528.426  111773.937 ? 1604.412 ns/op   1.06x (p = 0.000*)
  * = significant

-------------

Commit messages:
 - Further tuning, avoid unnecessary long conversions
 - Fix after merge
 - Merge optimization rework
 - Cleanup, further micro-optimization
 - Extract a state object and call that in a loop, shifting work from initCEN to checkAndAddEntry
 - Use zero as ZIP_ENDCHAIN marker to avoid the Arrays.fill
 - Avoid loading TreeSet
 - Going all the way
 - merge master
 - Use zero as ZIP_ENDCHAIN marker to avoid the Arrays.fill
 - ... and 5 more: https://git.openjdk.org/jdk/compare/ab06a878...19f33b8b

Changes: https://git.openjdk.org/jdk/pull/21133/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340571
  Stats: 152 lines in 2 files changed: 65 ins; 47 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/21133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21133/head:pull/21133

PR: https://git.openjdk.org/jdk/pull/21133

From pminborg at openjdk.org  Mon Sep 23 09:54:55 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 09:54:55 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

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 nine additional commits since the last revision:

 - Add specific message for group layouts with only padding layouts
 - Merge branch 'master' into linker-padding-layout-only
 - Check exception message
 - Remove redundant doc section
 - Merge branch 'master' into linker-padding-layout-only
 - Improve excception message
 - Document a sequence layout cannot contain a padding layout
 - Update copyright year
 - Prevent embeded only padding layout in linker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/d0575fd7..78d38efa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=01-02

  Stats: 1699 lines in 59 files changed: 1210 ins; 252 del; 237 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From mcimadamore at openjdk.org  Mon Sep 23 10:22:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 10:22:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
Message-ID: <3r7DCFYrcByzdnJaiwq56H_8RJrRqQPn2Fpm4ReHfqs=.6902bae4-f650-48be-b9ab-037e9a6acca4@github.com>

On Mon, 23 Sep 2024 09:54:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> 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 nine additional commits since the last revision:
> 
>  - Add specific message for group layouts with only padding layouts
>  - Merge branch 'master' into linker-padding-layout-only
>  - Check exception message
>  - Remove redundant doc section
>  - Merge branch 'master' into linker-padding-layout-only
>  - Improve excception message
>  - Document a sequence layout cannot contain a padding layout
>  - Update copyright year
>  - Prevent embeded only padding layout in linker

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 225:

> 223:     // check elements are not all padding layouts and for trailing padding
> 224:     private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {
> 225:         if (gl.memberLayouts().stream().allMatch(e -> e instanceof PaddingLayout)) {

I'm not 100% sure that this check (which I agree with) can be desumed from the current `Linker` javadoc. E.g. if I have:

`groupLayout(paddingLayout(1))`

The Linker says:
* there cannot be any intermediate padding more than necessary to align non-padding elements. But there's no non-padding elements here, so <shrug> :-)
* there cannot be more padding at the end, more than necessary to make the group size a multiple of its alignment - but again, since there's no non-padding layout, it is not clear what this means here. We have a padding of 1, which makes the group have size 1, which is a multiple of the alignment of the struct. So, ok?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771130016

From mcimadamore at openjdk.org  Mon Sep 23 10:30:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 10:30:18 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v4]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <Ft7DvxeKdG6qAy3iwGjwftyBUebtxvEhsIzJgQRet9M=.bc3400a7-2452-4100-8165-87fd40b43b0c@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert reference to caller stack

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/effefb50..eb2cc990

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From mcimadamore at openjdk.org  Mon Sep 23 10:38:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 10:38:37 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v4]
In-Reply-To: <Ft7DvxeKdG6qAy3iwGjwftyBUebtxvEhsIzJgQRet9M=.bc3400a7-2452-4100-8165-87fd40b43b0c@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <Ft7DvxeKdG6qAy3iwGjwftyBUebtxvEhsIzJgQRet9M=.bc3400a7-2452-4100-8165-87fd40b43b0c@github.com>
Message-ID: <Cy0X1ZHkyrwd_MlorYBQTfbvjHNy2AwHzH6HupiVrWc=.db0b3e8e-8f19-427f-9b9e-1a66eb685e0a@github.com>

On Mon, 23 Sep 2024 10:30:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert reference to caller stack

I've reverted the sentence that refers to "no caller class on the stack".

As for the remaining comments, I'm not sure how to proceed. Especially stuff like:

> though at the moment the restricted method text doesn't seem to talk about simple native method calls at all, so the reason for loadLibrary being restricted is not at all obvious IMO.

I don't see the connection between "restricted methods" and "simple native methods". Restricted methods, as per the new javadoc text:

> allow Java code to interoperate with resources outside the Java runtime in such a way that the runtime cannot prove correct or safe use of the resources

It is outside the scope of the javadoc text to state exactly *why* each restricted method is marked as such. In general, we do not provide many clarifications in any of the existing restricted methods, as the reason for "restrictedness" is rather obvious from reading the javadoc. In the case of `System::loadLibrary` things are more subtle, although, again, when reading the javadoc, the javadoc refers to the JNI specification, which then brings up `JNI_OnLoad` - e.g. loading a native library *might* result in the execution of native code - hence the restricted status.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2367829201

From pminborg at openjdk.org  Mon Sep 23 10:53:38 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 10:53:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <3r7DCFYrcByzdnJaiwq56H_8RJrRqQPn2Fpm4ReHfqs=.6902bae4-f650-48be-b9ab-037e9a6acca4@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
 <3r7DCFYrcByzdnJaiwq56H_8RJrRqQPn2Fpm4ReHfqs=.6902bae4-f650-48be-b9ab-037e9a6acca4@github.com>
Message-ID: <0sZoWoisyaE2m8lkpulrBE06n0t2cnJ-ZGI6dzDBxPM=.c3df9e43-de07-49d5-b6ca-7042174de003@github.com>

On Mon, 23 Sep 2024 10:19:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 nine additional commits since the last revision:
>> 
>>  - Add specific message for group layouts with only padding layouts
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Check exception message
>>  - Remove redundant doc section
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Improve excception message
>>  - Document a sequence layout cannot contain a padding layout
>>  - Update copyright year
>>  - Prevent embeded only padding layout in linker
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 225:
> 
>> 223:     // check elements are not all padding layouts and for trailing padding
>> 224:     private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {
>> 225:         if (gl.memberLayouts().stream().allMatch(e -> e instanceof PaddingLayout)) {
> 
> I'm not 100% sure that this check (which I agree with) can be desumed from the current `Linker` javadoc. E.g. if I have:
> 
> `groupLayout(paddingLayout(1))`
> 
> The Linker says:
> * there cannot be any intermediate padding more than necessary to align non-padding elements. But there's no non-padding elements here, so <shrug> :-)
> * there cannot be more padding at the end, more than necessary to make the group size a multiple of its alignment - but again, since there's no non-padding layout, it is not clear what this means here. We have a padding of 1, which makes the group have size 1, which is a multiple of the alignment of the struct. So, ok?

Previously, the check threw an `IllegalArgumentException` when presented with the above (or other) group layout with only padding layouts, but the actual message differed. So, this change only changes the exception message and does not change the current behavior. However, the question remains: Should we update the docs to reflect this behavior?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771187107

From pminborg at openjdk.org  Mon Sep 23 11:00:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 11:00:48 GMT
Subject: Integrated: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <C5QomCzTwznd3fbyem4Qw5a0sAbSZz4sP6voo078awM=.1566116d-8921-47a9-b87e-bf6d2ee3f0ed@github.com>

On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

This pull request has now been integrated.

Changeset: 384deda6
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/384deda65fd63e23d4caaaa9762f2ac80de78029
Stats:     442 lines in 31 files changed: 125 ins; 210 del; 107 mod

8325949: Create an internal utility method for creating VarHandle instances

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/20972

From lancea at openjdk.org  Mon Sep 23 11:04:24 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Sep 2024 11:04:24 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v5]
In-Reply-To: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
Message-ID: <dK-g0J-BXAZpZ10-d2gp4nfCUIvwRfbG5NjujxiU4fo=.cc21de8b-9489-4692-9d2c-a56ba9656034@github.com>

> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
> 
> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
> 
> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updates to CenSizeTooLarge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21003/files
  - new: https://git.openjdk.org/jdk/pull/21003/files/e250340b..0347a697

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21003&range=03-04

  Stats: 26 lines in 1 file changed: 6 ins; 15 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21003/head:pull/21003

PR: https://git.openjdk.org/jdk/pull/21003

From lancea at openjdk.org  Mon Sep 23 11:04:24 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Sep 2024 11:04:24 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v2]
In-Reply-To: <z21xVtgxymCMmCB1aTAQ5f6sRe6WmXbx5-BIqK210ek=.aa4f2a88-bc06-4cf7-babe-4013331355d5@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <vfetcws_O9JGH_FSIijdOD3XZohRob6Hfj6mlLQSWfc=.c714e76a-9ce8-43eb-90fa-727bbea6fb55@github.com>
 <ewyA7EVHOTG9ZafU_iWO5JiF8nWEN6PcWdwAJ2S9F48=.563b0a55-af1e-43ca-99c6-570807925481@github.com>
 <z21xVtgxymCMmCB1aTAQ5f6sRe6WmXbx5-BIqK210ek=.aa4f2a88-bc06-4cf7-babe-4013331355d5@github.com>
Message-ID: <uZEYWPTlWszjYXa_JY1-XbSQC0PSxBjpX_euDuTiDgs=.3222e2c9-239b-4b03-b8ce-e28cc9cc2253@github.com>

On Mon, 16 Sep 2024 11:42:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?
>> 
>> Also, since the combined header length clause applies to "any directory record", it also applies to LOC?
>> 
>> So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?
>> 
>> Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile. 
>> 
>> Some comments inline.
>
>> I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?
>> 
>> Also, since the combined header length clause applies to "any directory record", it also applies to LOC?
>> 
>> So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?
>> 
>> Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile.
>> 
>> Some comments inline.
> 
> As this is really a corner case at best, I decided to keep the changes to a minimum and the validation in writeCEN given that is where the encoded comment bytes are obtained and written out.

> @LanceAndersen
> 
> I had a look at your update of the `CenSizeTooLarge` test.
> 
> This test uses artificially large extra fields to produce a CEN size exceeding the implementation limit. Since this otherwise would create a lot of IO and a huge file, the test writes a sparse file until the last CEN record is written, after which real bytes are written out for the "ZIP64 End of Central Directory" and "End of Central Directory" records are written.
> 
> The current extra field size of 0xFFFF is too large to pass the combined length validation introduced by this PR. Because of this, the field size is reduced to account for the CENHDR length, the length of the entry name and the length of the comment (which is added to the last entry only)
> 
> Since the comment is only added to the last entry (as a hint to SparseOutputStream), the CEN_HEADER_SIZE no longer reflects the actual size of the CEN headers written. While the test still passes (by increasing NUM_ENTRIES as needed), this makes the test somewhat confusing for future maintainers.
> 
> Could we perhaps skip the comment altogether, and instead use equal-sized CEN records for all entries? Instead of using a comment as a signal to `SparseOutputStream` we could use a separate extra byte array on the last entry, as suggested in this diff on top of your PR:


Thanks for the suggestions to the test.  They look fine.  I have done a run across our internal Mach5 systems and no issues(as expected).

PR has been updated with these changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21003#issuecomment-2367883851

From mbaesken at openjdk.org  Mon Sep 23 11:15:36 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 23 Sep 2024 11:15:36 GMT
Subject: RFR: 8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from
 Windows coding
In-Reply-To: <c92Wa4D-tQXMfT7gxQD6WvM0EdKyG-j0WxSEfyoeSxo=.d0db3429-11d8-404b-885b-5bc1219efa11@github.com>
References: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
 <c92Wa4D-tQXMfT7gxQD6WvM0EdKyG-j0WxSEfyoeSxo=.d0db3429-11d8-404b-885b-5bc1219efa11@github.com>
Message-ID: <Ybn6i-L6A41jQFjTk3P4-_ZfAJM3kUYaeSmTJJt-MTw=.5e0b3efd-a697-48e2-98b4-1de61640903d@github.com>

On Mon, 23 Sep 2024 09:31:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems fine.
> 
> I thought we had eradicated ia64 from the codebase but it seems we missed a few things in hotspot too. :( I will file an issue to clean that up ...

Thanks for the reviews !

I noticed the HS ia64 references too but was not sure about all of those, maybe some have 'historical' value ;-) !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21130#issuecomment-2367906472

From mcimadamore at openjdk.org  Mon Sep 23 11:17:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 11:17:35 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <0sZoWoisyaE2m8lkpulrBE06n0t2cnJ-ZGI6dzDBxPM=.c3df9e43-de07-49d5-b6ca-7042174de003@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
 <3r7DCFYrcByzdnJaiwq56H_8RJrRqQPn2Fpm4ReHfqs=.6902bae4-f650-48be-b9ab-037e9a6acca4@github.com>
 <0sZoWoisyaE2m8lkpulrBE06n0t2cnJ-ZGI6dzDBxPM=.c3df9e43-de07-49d5-b6ca-7042174de003@github.com>
Message-ID: <aRqp-3QwrKPHBSb2if1mP6V-elX-g233DSb-rxk4oUg=.c82f6dcb-5793-4587-979b-15fd92d8b8ca@github.com>

On Mon, 23 Sep 2024 10:51:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 225:
>> 
>>> 223:     // check elements are not all padding layouts and for trailing padding
>>> 224:     private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {
>>> 225:         if (gl.memberLayouts().stream().allMatch(e -> e instanceof PaddingLayout)) {
>> 
>> I'm not 100% sure that this check (which I agree with) can be desumed from the current `Linker` javadoc. E.g. if I have:
>> 
>> `groupLayout(paddingLayout(1))`
>> 
>> The Linker says:
>> * there cannot be any intermediate padding more than necessary to align non-padding elements. But there's no non-padding elements here, so <shrug> :-)
>> * there cannot be more padding at the end, more than necessary to make the group size a multiple of its alignment - but again, since there's no non-padding layout, it is not clear what this means here. We have a padding of 1, which makes the group have size 1, which is a multiple of the alignment of the struct. So, ok?
>
> Previously, the check threw an `IllegalArgumentException` when presented with the above (or other) group layout with only padding layouts, but the actual message differed. So, this change only changes the exception message and does not change the current behavior. However, the question remains: Should we update the docs to reflect this behavior?

Note: I know the behavior in this particular case is not affected by the PR. That said, since you already need CSR for the "sequence with padding" behavioral change, I think it could make sense to piggy back on this PR, and clarify the javadoc for the other case as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771216722

From jvernee at openjdk.org  Mon Sep 23 11:47:45 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 11:47:45 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
 <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
Message-ID: <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>

On Mon, 23 Sep 2024 09:39:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We use "no caller class" in the CS methods, maybe it could be improved. 
>> 
>> I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.
>
> It is documented by the CS JEP: https://openjdk.org/jeps/176
> 
>> It discovers its caller's class by invoking the sun.reflect.Reflection.getCallerClass method.
> 
> CS set the precedent here and the terminology.

> I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.

I think saying 'no caller class on the stack' has the same effect though, unless someone knows how the implementation works (which may not be unreasonable), and is aware of the scenario where a java method is called from a new native thread. I thought it would look cleaner to have this be more 'explicitly unspecified' instead. But, maybe having something (vague or not), is better than nothing...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1771253876

From redestad at openjdk.org  Mon Sep 23 11:59:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Sep 2024 11:59:08 GMT
Subject: RFR: 8340571: Outline code from the loop in ZipFile.Source.initCen
 [v2]
In-Reply-To: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
References: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
Message-ID: <HIYiejIdVbY-aPW9LKvGWX_WZqa63sJvLrOgmED_wfE=.fa76ff69-52ae-4293-b44b-37659fe26829@github.com>

> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic as possible into the per-entry method processor. This inner method will be called often and JIT optimized earlier in the bootstrap sequence.
> 
> Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both my M1 macbook and my x64 wokstation, while we also improve on relevant throughput microbenchmarks:
> 
> 
> Name               (size) Cnt       Base      Error        Test      Error  Unit  Change
> openCloseZipFile      512  15  61372.449 ? 1197.432   58081.423 ? 1751.988 ns/op   1.06x (p = 0.000*)
> openCloseZipFile     1024  15 117953.727 ? 3202.274  112548.875 ? 5126.665 ns/op   1.05x (p = 0.001*)
> openCloseZipFilex2    512  15  62141.795 ?  674.121   60520.017 ? 2438.346 ns/op   1.03x (p = 0.017 )
> openCloseZipFilex2   1024  15 117959.071 ? 1528.426  111773.937 ? 1604.412 ns/op   1.06x (p = 0.000*)
>   * = significant

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fix botched merge, improve overflow conciousness

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21133/files
  - new: https://git.openjdk.org/jdk/pull/21133/files/19f33b8b..f0011e4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21133&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21133&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21133/head:pull/21133

PR: https://git.openjdk.org/jdk/pull/21133

From jvernee at openjdk.org  Mon Sep 23 12:11:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 12:11:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
 <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
 <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>
Message-ID: <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>

On Mon, 23 Sep 2024 11:45:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> It is documented by the CS JEP: https://openjdk.org/jeps/176
>> 
>>> It discovers its caller's class by invoking the sun.reflect.Reflection.getCallerClass method.
>> 
>> CS set the precedent here and the terminology.
>
>> I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.
> 
> I think saying 'no caller class on the stack' has the same effect though, unless someone knows how the implementation works (which may not be unreasonable), and is aware of the scenario where a java method is called from a new native thread. I thought it would look cleaner to have this be more 'explicitly unspecified' instead. But, maybe having something (vague or not), is better than nothing...

> It is documented by the CS JEP: https://openjdk.org/jeps/176

I read the JEP, but it only refers to `sun.reflect.Reflection.getCallerClass`, which is an internal API that I don't expect external users to know about/understand.

To be clear: I don't think we should explain exactly how CS methods determine the caller. IMO, the fact that this is implemented using a stack walk is an implementation detail that users shouldn't have to know about (and it seems plausible for VM implementations to use other mechanisms).

In lieu of that, I think it would be better to say that: in general (depending on the VM impl) there may be cases in which the caller can not be determined, and then as an example explicitly enumerate the cases in which the caller class can not be determined. That explanation can then be linked to from the CS methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1771281291

From jvernee at openjdk.org  Mon Sep 23 12:19:40 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 12:19:40 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <aRqp-3QwrKPHBSb2if1mP6V-elX-g233DSb-rxk4oUg=.c82f6dcb-5793-4587-979b-15fd92d8b8ca@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
 <3r7DCFYrcByzdnJaiwq56H_8RJrRqQPn2Fpm4ReHfqs=.6902bae4-f650-48be-b9ab-037e9a6acca4@github.com>
 <0sZoWoisyaE2m8lkpulrBE06n0t2cnJ-ZGI6dzDBxPM=.c3df9e43-de07-49d5-b6ca-7042174de003@github.com>
 <aRqp-3QwrKPHBSb2if1mP6V-elX-g233DSb-rxk4oUg=.c82f6dcb-5793-4587-979b-15fd92d8b8ca@github.com>
Message-ID: <LHhfMsP7wsWuyzph_pkQFtQhgmZIJ1PG16-9YTlRNJ0=.9e76ae31-e96c-4e5d-86e8-5a7b975ac365@github.com>

On Mon, 23 Sep 2024 11:15:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Previously, the check threw an `IllegalArgumentException` when presented with the above (or other) group layout with only padding layouts, but the actual message differed. So, this change only changes the exception message and does not change the current behavior. However, the question remains: Should we update the docs to reflect this behavior?
>
> Note: I know the behavior in this particular case is not affected by the PR. That said, since you already need CSR for the "sequence with padding" behavioral change, I think it could make sense to piggy back on this PR, and clarify the javadoc for the other case as well.

> We have a padding of 1, which makes the group have size 1, which is a multiple of the alignment of the struct. So, ok?

This is a good example. This seems to satisfy the rules, but is rejected at the moment. I agree, we probably need to mention that structs with _just_ padding (or sequences thereof) are not allowed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771295525

From kcr at openjdk.org  Mon Sep 23 12:51:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 23 Sep 2024 12:51:38 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <umhdvXQEepk2KYi0pcub_yjju5pXQ-Q_dDIN9GrHOkE=.608f2cc0-6c30-4157-9454-b6120fbf6c07@github.com>

On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

Yes, this was on hold for a couple weeks; I plan to write the CSR this week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2368124430

From duke at openjdk.org  Mon Sep 23 13:39:36 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 23 Sep 2024 13:39:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
Message-ID: <tjV2ovdgpc5DiBzzE3IVECNGfQaEd1BCSgyhrXIGHGA=.2f937464-f826-41af-90d2-dc8406e99428@github.com>

On Mon, 23 Sep 2024 09:54:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> 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 nine additional commits since the last revision:
> 
>  - Add specific message for group layouts with only padding layouts
>  - Merge branch 'master' into linker-padding-layout-only
>  - Check exception message
>  - Remove redundant doc section
>  - Merge branch 'master' into linker-padding-layout-only
>  - Improve excception message
>  - Document a sequence layout cannot contain a padding layout
>  - Update copyright year
>  - Prevent embeded only padding layout in linker

Hello! As the author of the original issue, I am interested in the ability to leave comments on my issues before creating a pull request on github. The site bugreport.java.com does not provide this ability for unregistered users, but registration is non-trivial. How can I do this?

P.S. I am creating a port of the FFM API to Android, which is already +- ready. In the process, a number of questions have accumulated, which I am later going to formalize as issues

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2368289445

From jvernee at openjdk.org  Mon Sep 23 13:48:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 13:48:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v3]
In-Reply-To: <tjV2ovdgpc5DiBzzE3IVECNGfQaEd1BCSgyhrXIGHGA=.2f937464-f826-41af-90d2-dc8406e99428@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <pjSbHybf2-2ike3C1WHEBjql2JkHix7pEqw0LzYv9ec=.d2ef9716-86f2-4a2a-89f4-93288f7aabbd@github.com>
 <tjV2ovdgpc5DiBzzE3IVECNGfQaEd1BCSgyhrXIGHGA=.2f937464-f826-41af-90d2-dc8406e99428@github.com>
Message-ID: <avIxEW0UgXPFbzr3lIYD6jHApftKg7pB4vFGnDHG7_M=.26c25151-a975-4cd7-a0bc-de93300db246@github.com>

On Mon, 23 Sep 2024 13:37:07 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

>> 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 nine additional commits since the last revision:
>> 
>>  - Add specific message for group layouts with only padding layouts
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Check exception message
>>  - Remove redundant doc section
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Improve excception message
>>  - Document a sequence layout cannot contain a padding layout
>>  - Update copyright year
>>  - Prevent embeded only padding layout in linker
>
> Hello! As the author of the original issue, I am interested in the ability to leave comments on my issues before creating a pull request on github. The site bugreport.java.com does not provide this ability for unregistered users, but registration is non-trivial. How can I do this?
> 
> P.S. I am creating a port of the FFM API to Android, which is already +- ready. In the process, a number of questions have accumulated, which I am later going to formalize as issues

@vova7878 To leave comments in JBS you need to have the 'Author' role in the OpenJDK project. This role is typically only granted to people who already have had some involvement in OpenJDK. See: https://openjdk.org/projects/#project-author

I suggest you send emails to the `panama-dev at openjdk.org` mailing list with the issues you find, which allows for back-and-forth, and then we can file them in JBS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2368313222

From pminborg at openjdk.org  Mon Sep 23 13:54:52 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 13:54:52 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v4]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add to specification and refine detection of PL GLs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/78d38efa..bba0b784

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=02-03

  Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From mcimadamore at openjdk.org  Mon Sep 23 14:46:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 14:46:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v4]
In-Reply-To: <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>
Message-ID: <ZAvWcsyTtdkyPcQT1RfGJNigwtDu1WEN75y6DvuTveY=.25b4bb4d-1581-4075-92a7-89a19130b83e@github.com>

On Mon, 23 Sep 2024 13:54:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add to specification and refine detection of PL GLs

src/java.base/share/classes/java/lang/foreign/Linker.java line 264:

> 262:  * <li>{@code G} does not contain padding other than what is strictly required to align
> 263:  *      its non-padding layout elements, or to satisfy (2), and</li>
> 264:  * <li>{@code G} is {@code G.memberLayouts().isEmpty()} or (at the same time) not all

I think @JornVernee mentioned that empty layouts are ok and/or accepted by C compilers. We just don't know what to do with padding-only groups.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771591756

From jvernee at openjdk.org  Mon Sep 23 14:46:38 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 14:46:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v4]
In-Reply-To: <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>
Message-ID: <HIn5d9JdkSp1IA2HphH8--Ve3AW7krBGAqDoMYau2Ew=.1e88f361-8140-418d-9ef3-b7ffb192fe15@github.com>

On Mon, 23 Sep 2024 13:54:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add to specification and refine detection of PL GLs

src/java.base/share/classes/java/lang/foreign/Linker.java line 265:

> 263:  *      its non-padding layout elements, or to satisfy (2), and</li>
> 264:  * <li>{@code G} is {@code G.memberLayouts().isEmpty()} or (at the same time) not all
> 265:  * elements are padding layouts.</li>

I suggest splitting the last list item into 2. The prior item also needs to be cleaned up (replace `, and` with `;`).

Not sure what you mean here with 'at the same time'? An empty group layout can not contain padding layouts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771590123

From jvernee at openjdk.org  Mon Sep 23 14:46:38 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 14:46:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v4]
In-Reply-To: <HIn5d9JdkSp1IA2HphH8--Ve3AW7krBGAqDoMYau2Ew=.1e88f361-8140-418d-9ef3-b7ffb192fe15@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>
 <HIn5d9JdkSp1IA2HphH8--Ve3AW7krBGAqDoMYau2Ew=.1e88f361-8140-418d-9ef3-b7ffb192fe15@github.com>
Message-ID: <OerYQPXmNjWgQq1vASU-ZIyOa0a9sK0SCXaw3-JS58g=.41ea1e23-e426-4e80-b7e1-4b01dad25f32@github.com>

On Mon, 23 Sep 2024 14:40:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add to specification and refine detection of PL GLs
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 265:
> 
>> 263:  *      its non-padding layout elements, or to satisfy (2), and</li>
>> 264:  * <li>{@code G} is {@code G.memberLayouts().isEmpty()} or (at the same time) not all
>> 265:  * elements are padding layouts.</li>
> 
> I suggest splitting the last list item into 2. The prior item also needs to be cleaned up (replace `, and` with `;`).
> 
> Not sure what you mean here with 'at the same time'? An empty group layout can not contain padding layouts.

I think it might be enough to just mention that not only padding layouts are allowed. The list is for things that should all be true, so adding an 'or' condition in there seems a bit confusing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771596648

From asemenyuk at openjdk.org  Mon Sep 23 14:49:36 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 23 Sep 2024 14:49:36 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v2]
In-Reply-To: <zTmFS6P1n5OJukT9nNhCU1gbXAIepfPB50sz3WIK-Bo=.8fe7870f-0d62-47c6-8cf3-75dedc452b95@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <h5MO_8o3QXVF6PGRrpcPhtmmz9uArXu5q5lYBzhg7DM=.47f97ff2-bc0f-4fe5-ad11-2fec0cfded2f@github.com>
 <zTmFS6P1n5OJukT9nNhCU1gbXAIepfPB50sz3WIK-Bo=.8fe7870f-0d62-47c6-8cf3-75dedc452b95@github.com>
Message-ID: <C97v0r3yTjNalV2NAELmNCyqSo8CxHktoJRV6m6BVqY=.5aa5e180-ecbb-4e0f-95d6-a70b65fe2526@github.com>

On Fri, 20 Sep 2024 21:47:08 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Redo removal of `resource.wxl-file-name` property
>>  - Revert "8338918: Remove non translated file name from WinResources resource bundle"
>>    
>>    This reverts commit 9b3c1a59d48ec9e87bd1d4c37c9789ff1656a02c.
>
> Looks good.

@sashamatveev please review the latest commit. It fixes the order of modifiers. It blocks integration

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21100#issuecomment-2368510529

From asotona at openjdk.org  Mon Sep 23 15:18:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 23 Sep 2024 15:18:39 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v6]
In-Reply-To: <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>
Message-ID: <vOkJrhq-y3pIGXgz8mRekQ2aE-ObLLFGQchfs3lZPfQ=.25c14513-3a18-46ad-a83a-1a285b4bb504@github.com>

On Tue, 10 Sep 2024 21:18:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - omission in tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Rename constants at new locations, link to related factories, cp tag constant names
>  - Fix compile errors
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Compile errors; now tests are all green.
>  - Move Constant Pool tags to PoolEntry
>    
>    Two unexpected usages in jlink raw processing, but rest is fine
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6fd043f1...fa9ea36d

src/java.base/share/classes/java/lang/classfile/Opcode.java line 1133:

> 1131:      */
> 1132:     @PreviewFeature(feature = PreviewFeature.Feature.CLASSFILE_API)
> 1133:     public static final class OpcodeValues {

I think we should not introduce a new API class just to expose int constants we plan to hide under the Opcode.
My proposal is to hard-code the opcodes in the Opcode initialization and remove OpcodeValues class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1771654912

From viktor.klang at oracle.com  Mon Sep 23 15:19:48 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 23 Sep 2024 15:19:48 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <46bc86380b39b14b20d3d1e589015594b15c1189@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
 <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>
 <MW4PR10MB57741DBB8EC8562AD2224B1EFF632@MW4PR10MB5774.namprd10.prod.outlook.com>
 <46bc86380b39b14b20d3d1e589015594b15c1189@anthonyv.be>
Message-ID: <MW4PR10MB577469B9A299BC7EC6D62779FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Anthony,

>The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.

Even if this is well-intentioned, my experience tells me that this feedback will not materialize, and trying to provoke conformance at runtime will have a noticeable performance impact not encumbering other intermediate operations, especially for processing the bulk majority of streams (which tend to be less than 10 elements in size).

>This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".

Adding clarifications to the Javadoc may be the most balanced path forward, in doing so we're talking updating the documentation for both Gatherer and Collector.

>Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it?

No, that would be "moving the goalposts" i.e. making Gatherers specified more loosely. Developers will write the code that they write, but if something isn't behaving as expected, it is important to know which side to debug?the library or the user code.

> I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers.

The ability for developers to implement interfaces (knowingly or unknowingly) in non-spec-conforming ways aside, are you suggesting that we add a section in the Gatherer (and Collector) in the form of "Implementor Notes" that are a bit more high-level than the specification?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Anthony Vanelverdinghe <dev at anthonyv.be>
Sent: Thursday, 19 September 2024 20:57
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback

Hi Viktor

> Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather).

The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.
This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".

> java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?

For `Stream` the package Javadoc has statements like "No storage. A stream is not a data structure" and "Possibly unbounded.", which is sufficient rationale to me.
For `Collector`, unless I'm missing something, it does not actually specify that it must be reusable, so it does not have to provide a rationale for it either. Even if I did miss something and reusability is implied from the specification: the question would likely never come up, because a Collector will in practice always be reusable anyway (read: I can't readily think of a sensible non-reusable Collector). This is unlike Gatherer, where some obvious use cases such as `concat` and `zip` exist and people like me wonder why such use cases are, apparently needlessly, prohibited by the Gatherer specification.

> Think of it more like increasing the odds that users are given spec-conformant Gatherers.

Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it? I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers. Gunnar wrote a blog post [https://urldefense.com/v3/__https://www.morling.dev/blog/zipping-gatherer/__;!!ACWV5N9M2RV99hQ!KmRJAZ0OMfv5XrDKYFVNTJyVWBah899OR9tdZKUHJB928SXc6VEdT4ni1AHI_lGezKchV9kYO04XUdClsg$ ] about his `zip` Gatherer saying "Java 22 [...] promises to improve the situation here." and none of his readers pointed out that his Gatherer is not compliant either (nor complained that his Gatherer is not reusable).

Kind regards, Anthony

September 19, 2024 at 11:30 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> Hi Anthony,
>
> Bear with me for a moment,
>
> in the same vein as there's nothing which *enforces* equals(?) or hashCode() to be conformant to their specs, or any interface-implementation for that matter, I don't see how we could make any stronger enforcement of Gatherers.
>
> >My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
>
> Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather). Ultimately, it all boils down to specification?if an equals(?)-method implementation leads to surprising behavior when used with a collection, one typically needs to first ensure that the equals(?)-method conforms to its expected specification before one can presume that the collection has a bug.
>
> For the "just work"?scenario, one can only make claims about things which have been proven. So in this case, what tests have passed for the implementation in question?
>
> >Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction.
> java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?
>
> > "protecting the users from being given non-reusable Gatherers"
> Think of it more like increasing the odds that users are given spec-conformant Gatherers.
>
> Cheers,
>
> ?
>
> **Viktor Klang**
> Software Architect, Java Platform Group
>
> Oracle
>
> ????????????????????????????????????????????????????????????????
>
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Wednesday, 18 September 2024 18:27
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
>
> Hi Viktor
>
> Let me start with a question: is the requirement (a) "a Gatherer SHOULD be reusable", or (b) "a Gatherer MUST be reusable"?
>
> As of today the specification says (b), whereas the implementation matches (a).
>
> In case of (a), I propose to align the specification to allow for compliant, non-reusable Gatherers.
>
> In case of (b), I propose to align the implementation to enforce compliance. Something like:
>
> (1) invoke `initializer()` twice, giving `i1` and `i2`. Discard `i1` and invoke `i2` twice, giving `state1` and `state2`.
>
> (2) invoke `finisher()` twice, giving `f1` and `f2`. Discard `f1` and invoke `f2` twice, the first time with `state1` and a dummy Downstream, the second time with the actual final state, i.e. `state2` after all elements were integrated, and the actual Downstream.
>
> Then backport this change to JDK 23 & 22 and/or do another round of preview in JDK 24.
>
> I'm confident that enforcing compliance would result in significant amounts of feedback questioning the requirement.
>
> My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
>
> Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction. You say:
>
> > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
>
> so I'd guess the rationale is "protecting the users from being given non-reusable Gatherers".
>
> However, I can't readily think of a situation where this would be essential.
>
> If a user creates a Gatherer by invoking a factory method, the factory method can specify whether its result is reusable.
>
> And if a user is given a Gatherer as a method argument, and they need the Gatherer to be reusable, they could change the parameter to a `Supplier<Gatherer>` instead.
>
> > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
>
> >
>
> > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
>
> We agree, just that I'd provide 2 factory methods, `concat(Stream<T>)` (non-reusable) and `append(List<T>)` (reusable), whereas you'd provide a 2-in-1 `concat(Supplier<Stream<T>>)`.
>
> Kind regards, Anthony
>
> September 12, 2024 at 11:55 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > Hi Anthony
>
> >
>
> > Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.
>
> >
>
> > >While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
>
> >
>
> > To me, this is governed by the following parts of the Gatherer specification https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html :
>
> >
>
> > "Each invocation of initializer() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer() ,integrator()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator() ,combiner()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner() , and finisher()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher()  must return a semantically identical result."
>
> >
>
> > and
>
> >
>
> > "Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstreamGatherer.Downstreamhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html PREVIEWhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream  for longer than the invocation duration of the method which they are passed to."
>
> >
>
> > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
>
> >
>
> > For Stream, the assumption is that they are NOT reusable at all.
>
> > For Gatherer, I think the only reasonable assumption is that they are reusable.
>
> >
>
> > >In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?
>
> >
>
> > Not necessarily, if the factory method **consumes** the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.
>
> >
>
> > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
>
> >
>
> > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
>
> >
>
> > >As another example, take Gunnar Morling's zip Gatherers:
>
> >
>
> > I don't see how Gatherers like this could be made reusable, or why that would even be desirable.
>
> >
>
> > Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().
>
> >
>
> > >My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
>
> >
>
> > My apologies, I misunderstood. To me, the operation you describe is called `inject`.
>
> > Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.
>
> >
>
> > Thanks again for the great questions and conversation, it's valuable!
>
> > Cheers,
>
> >
>
> > ?
>
> >
>
> > **Viktor Klang**
>
> > Software Architect, Java Platform Group
>
> >
>
> > Oracle
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/8d4bae5f/attachment-0001.htm>

From liach at openjdk.org  Mon Sep 23 15:21:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 15:21:38 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v6]
In-Reply-To: <vOkJrhq-y3pIGXgz8mRekQ2aE-ObLLFGQchfs3lZPfQ=.25c14513-3a18-46ad-a83a-1a285b4bb504@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <VdX_9WvQ8zr7JNBEk7y1X3rZg3UkfPNQMKdzbLtDKxg=.ab540ff9-40c8-4699-8a5e-70f6d85e077e@github.com>
 <vOkJrhq-y3pIGXgz8mRekQ2aE-ObLLFGQchfs3lZPfQ=.25c14513-3a18-46ad-a83a-1a285b4bb504@github.com>
Message-ID: <sohWBZe6TDMf9aWoj9v4154DJHrScji85jlZktxYBI0=.875b8eee-e7b1-4432-a210-709893b569f6@github.com>

On Mon, 23 Sep 2024 15:15:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - omission in tests
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Rename constants at new locations, link to related factories, cp tag constant names
>>  - Fix compile errors
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>>  - Compile errors; now tests are all green.
>>  - Move Constant Pool tags to PoolEntry
>>    
>>    Two unexpected usages in jlink raw processing, but rest is fine
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6fd043f1...fa9ea36d
>
> src/java.base/share/classes/java/lang/classfile/Opcode.java line 1133:
> 
>> 1131:      */
>> 1132:     @PreviewFeature(feature = PreviewFeature.Feature.CLASSFILE_API)
>> 1133:     public static final class OpcodeValues {
> 
> I think we should not introduce a new API class just to expose int constants we plan to hide under the Opcode.
> My proposal is to hard-code the opcodes in the Opcode initialization and remove OpcodeValues class.

I think we can move these values to an implementation class like `RawBytecodeHelper` as we make use of these values. We can always move these constants back if there is need.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1771661393

From asotona at openjdk.org  Mon Sep 23 15:25:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 23 Sep 2024 15:25:37 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v4]
In-Reply-To: <Lkq8nZbd4uxxa0wmRpuCmEqPHKwvJ1D_ttwld32MXN4=.4ff64632-a2e4-4919-8696-6e581940f22b@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <Lkq8nZbd4uxxa0wmRpuCmEqPHKwvJ1D_ttwld32MXN4=.4ff64632-a2e4-4919-8696-6e581940f22b@github.com>
Message-ID: <u4hBnbDBrOHmffD9k0mOCkFUNsmvzr453LLRtlmfL2w=.00325a8f-9175-4e73-b0cb-8da5fef670e7@github.com>

On Thu, 19 Sep 2024 18:02:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Fresh creation bench
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3bb8de31...eed09345

It looks good to me.
I would just suggest to look more deeply on test coverage of hash computation for various UTF8Entry states (probably in an extra bug).

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20667#pullrequestreview-2322627716

From alanb at openjdk.org  Mon Sep 23 15:29:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 15:29:40 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v9]
In-Reply-To: <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>
Message-ID: <H3xkGa0GcsOwrZa5RtNzBUN9Trj474TLoE5WP8K_KVw=.c066a841-98a6-41ee-af97-0371552f8768@github.com>

On Mon, 23 Sep 2024 04:53:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - David's review for code comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - David's review for code comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - David's review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

My comments have been addressed, no other issues from me.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20997#pullrequestreview-2322637700

From viktor.klang at oracle.com  Mon Sep 23 15:38:28 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 23 Sep 2024 15:38:28 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <CANSoFxsGW78wGHG2MS3PKXPUSmT1hyT4ViBOTxx9pMEvMeXnLg@mail.gmail.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <CANSoFxsGW78wGHG2MS3PKXPUSmT1hyT4ViBOTxx9pMEvMeXnLg@mail.gmail.com>
Message-ID: <MW4PR10MB5774E9E5E12DAF53DAFE7F96FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Archie!

>I recently encountered a real-world use case for Stream Gatherers and thought I'd mention it (apologies if you've seen these ideas already). These might even be worth considering including as standard offerings.

No need to preface your email with an apology ? I'm happy to get thoughts, feedback, and ideas!

You have a pretty interesting use-case, and performing a "sub-group reorder" is an interesting use-case.
Pulling on that string a bit more, it would seem like its primary use-cases would lie in scenarios where you're consuming things like data files (think CSVs etc where there's a predefined order/grouping to the entries) or consuming things like database results, would that be a fair characterization?

Interestingly, one of the exercises I went through during the design of Gatherer was to reimplement the java.util.stream.Stream interface only using Gatherer and Collector, so I took a stab at things like sorted() etc. As is common in the situation of operating on top of pre-ordered data, parallelization tends to be costly to implement (either by having to forego it, or by needing to perform much of the operation in the finisher after aggregating elements in the integrator).

Quickly thinking about the operation, I presume you'd need to be able to track the current "primary group", collect elements into something like an ArrayList, and upon switching to a new primary group, you sort the list according to the secondary group, emit all elements for as long as Downstream::push allows you to, clear the list, enqueue the new element which had the new primary group. Then in the finisher you perform the same operation, presuming that that's the signal that there's no more elements in the last primary group.

But I think you can relax the requirement that the primary group must be Comparable, you only need to have a BiPredicate and test (prev, next) for sameness, and if you get false, you presume that `next` belongs to a new primary group. But since you're going to sort the group on the secondary, that'll need to be comparable.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Archie Cobbs <archie.cobbs at gmail.com>
Sent: Friday, 20 September 2024 19:20
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback

Hi Viktor,

I recently encountered a real-world use case for Stream Gatherers and thought I'd mention it (apologies if you've seen these ideas already). These might even be worth considering including as standard offerings.

Motivating example: Suppose you have a large list of people sorted by LastName. Your goal is to print the list ordered by LastName, then by FirstName. The list is too large to re-sort the whole thing.

Instead, you only need to "fixup" the ordering, by re-sorting just the groups of people with the same last name.

If you happen to know that there are no more than 100 people with the exact same last nam, then one option would be a Gatherer that re-sorts a stream, but only up to some maximum window size (if two elements were out of order and separated by more than the window size, then sorted output would no longer be guaranteed).

In the above example, you would set the window size to 100 and it might look something like this:

listOfPeople.stream()   // sorted by lastName only
  .gather(Gatherers.windowSort(100, Comparator.comparing(Person::lastName).thenComparing(Person::firstName)));

Another (probably better) option would be a "secondary sort" Gatherer. This would take an already sorted stream and then apply a secondary sort. It would collect items having the same primary sort key (however many there were), and then re-sort those groups all at once using the secondary key:

listOfPeople.stream()   // sorted by lastName only
  .gather(Gatherers.secondarySort(Comparator.comparing(Person::lastName), Comparator.comparing(Person::firstName)));

This kind of thing is common when querying a database that doesn't have the required composite index corresponding to a desired composite sort, e.g., there is an index on LastName and an index on FirstName, but no composite index on LastName+FirstName, etc.

-Archie

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/a71f863d/attachment-0001.htm>

From alanb at openjdk.org  Mon Sep 23 16:04:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 16:04:43 GMT
Subject: RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header
 field limits [v5]
In-Reply-To: <dK-g0J-BXAZpZ10-d2gp4nfCUIvwRfbG5NjujxiU4fo=.cc21de8b-9489-4692-9d2c-a56ba9656034@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
 <dK-g0J-BXAZpZ10-d2gp4nfCUIvwRfbG5NjujxiU4fo=.cc21de8b-9489-4692-9d2c-a56ba9656034@github.com>
Message-ID: <9Q02eeDm8IXyGsInjvrsbpL5qH_il3hAtEITnNo_5z0=.bcdc4d35-c4b8-4bed-a06a-65d6cdc1f648@github.com>

On Mon, 23 Sep 2024 11:04:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates to CenSizeTooLarge

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21003#pullrequestreview-2322728258

From lancea at openjdk.org  Mon Sep 23 16:09:44 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Sep 2024 16:09:44 GMT
Subject: Integrated: 8336025: Improve ZipOutputSream validation of MAX CEN
 Header field limits
In-Reply-To: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
References: <pHyv1dK0BmdnyP6cZKTGRX8uehu0pB8M8CsAGj1nGrI=.1206e605-40e4-4f36-bc6a-8b00968871e3@github.com>
Message-ID: <SbY0bsREVYdSg_UYley_bnv02WrxYBhSAhmlM9xrpTY=.ec0a649b-53dc-4940-ac31-688b5c755841@github.com>

On Fri, 13 Sep 2024 17:40:21 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
> 
> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
> 
> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass

This pull request has now been integrated.

Changeset: 0f9f7775
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f9f777520c5341be1e9f985f41304a297b08936
Stats:     230 lines in 4 files changed: 196 ins; 20 del; 14 mod

8336025: Improve ZipOutputSream validation of MAX CEN Header field limits

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21003

From duke at openjdk.org  Mon Sep 23 16:26:45 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 23 Sep 2024 16:26:45 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v12]
In-Reply-To: <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
Message-ID: <D314fEvw6CiZJdBaX6EK7JScjIasx2GooWsjUltaD6U=.fac7205b-8bee-4cd0-a30e-0b9dd6caccbb@github.com>

On Thu, 19 Sep 2024 21:15:11 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix is_intrinsic_supported to work properly

Hello Vladimir (@vnkozlov),

Could you please run the tests for this PR and let us know?
We're hoping to integrate this PR soon.

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2368777178

From bpb at openjdk.org  Mon Sep 23 16:29:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Sep 2024 16:29:15 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v5]
In-Reply-To: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
Message-ID: <BpGfUItTokUXYypzo7ni4ZankbQqbbinPc8vQn4Mk58=.37a15287-7619-45b0-966d-45c8904cb59a@github.com>

> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8336895: Modify "More than one instance" paragraphs and convert to API notes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20320/files
  - new: https://git.openjdk.org/jdk/pull/20320/files/d6831f92..503d123a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=03-04

  Stats: 17 lines in 4 files changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20320.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20320/head:pull/20320

PR: https://git.openjdk.org/jdk/pull/20320

From bpb at openjdk.org  Mon Sep 23 16:29:16 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Sep 2024 16:29:16 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <KUKq2zJNpjjIK_JFCBwXKSeq8wrx0vhjF7WRevd_ePU=.591d3058-2569-473b-91e7-97a3fce9aab4@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>
 <KUKq2zJNpjjIK_JFCBwXKSeq8wrx0vhjF7WRevd_ePU=.591d3058-2569-473b-91e7-97a3fce9aab4@github.com>
Message-ID: <VKuKiNCNY5jswQxWUjHOd4dxPwNcGNQsbCjjyYF1jNE=.a2a41a15-ccde-4a4a-9a3c-bb8fa05a9f71@github.com>

On Sat, 21 Sep 2024 15:01:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8336895: "  Doing" -> " Doing" and add some {@code} tags
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 58:
> 
>> 56:  * incorrect result since each instance of {@code BufferedInputStream}
>> 57:  * maintains its own state.
>> 58:  *
> 
> It might be clearer to just say that once wrapped with a BIS, the underlying input stream should not be used directly or wrapped with another stream. This is potentially something for an apiNote as it's more about API usage,

Verbiage changed and converted to an `apiNote` in 503d123.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1771754675

From kcr at openjdk.org  Mon Sep 23 16:32:23 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 23 Sep 2024 16:32:23 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v2]
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <Sgi1WKvchV1LRS-hPO7eUZIaCWXjfCDLCLidsn1kYts=.944d041e-24f0-4938-877c-7cd95641506e@github.com>

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

Kevin Rushforth 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 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Update javadoc
 - Update copyright years
 - Merge branch 'master' into 8311530-depr-jsobject
 - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
 - 8311530: Deprecate jdk.jsobject module for removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20555/files
  - new: https://git.openjdk.org/jdk/pull/20555/files/c3ee6ad3..d2ff851c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=00-01

  Stats: 168234 lines in 1172 files changed: 155508 ins; 7077 del; 5649 mod
  Patch: https://git.openjdk.org/jdk/pull/20555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555

PR: https://git.openjdk.org/jdk/pull/20555

From pminborg at openjdk.org  Mon Sep 23 16:35:18 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 16:35:18 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reword doce

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/bba0b784..b755c61d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From pminborg at openjdk.org  Mon Sep 23 16:35:18 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 16:35:18 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v4]
In-Reply-To: <OerYQPXmNjWgQq1vASU-ZIyOa0a9sK0SCXaw3-JS58g=.41ea1e23-e426-4e80-b7e1-4b01dad25f32@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <NJnXMoVFNe4g6ERTKdPKtSNiQN16wcCGXDoeWPKuByc=.500127ca-a54c-45b3-af38-a1754bdd4334@github.com>
 <HIn5d9JdkSp1IA2HphH8--Ve3AW7krBGAqDoMYau2Ew=.1e88f361-8140-418d-9ef3-b7ffb192fe15@github.com>
 <OerYQPXmNjWgQq1vASU-ZIyOa0a9sK0SCXaw3-JS58g=.41ea1e23-e426-4e80-b7e1-4b01dad25f32@github.com>
Message-ID: <_iuKFRe5BBHuZzcqvrRFK1gvD-I3rbCcNFVA10bEoYo=.c4f2f4f5-e04f-4512-a945-31194d523294@github.com>

On Mon, 23 Sep 2024 14:43:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 265:
>> 
>>> 263:  *      its non-padding layout elements, or to satisfy (2), and</li>
>>> 264:  * <li>{@code G} is {@code G.memberLayouts().isEmpty()} or (at the same time) not all
>>> 265:  * elements are padding layouts.</li>
>> 
>> I suggest splitting the last list item into 2. The prior item also needs to be cleaned up (replace `, and` with `;`).
>> 
>> Not sure what you mean here with 'at the same time'? An empty group layout can not contain padding layouts.
>
> I think it might be enough to just mention that not only padding layouts are allowed. The list is for things that should all be true, so adding an 'or' condition in there seems a bit confusing.

My attempt with the "at the same time" was to emphasize that it is `and ... and (... or ..)` but maybe that is too hard to see. I initially had `and (not empty and not all are padding layout)` but used De Morgan's law. I've rewritten the docs now to something that is hopefully better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771764478

From mcimadamore at openjdk.org  Mon Sep 23 16:42:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 16:42:42 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <2e6M3FfXhdHJ1KtFnemnATPbuBsQ9a8BciCyWS83AUc=.1544705e-9fbc-4571-9f4b-8ede5070d56e@github.com>

On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword doce

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 225:

> 223:     // check elements are not all padding layouts and for trailing padding
> 224:     private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {
> 225:         if (!gl.memberLayouts().isEmpty() && gl.memberLayouts().stream().allMatch(e -> e instanceof PaddingLayout)) {

You have fixed the javadoc - but the check for `memberLayouts().isEmpty()` is still here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771774880

From archie.cobbs at gmail.com  Mon Sep 23 16:53:48 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 23 Sep 2024 11:53:48 -0500
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB5774E9E5E12DAF53DAFE7F96FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <CANSoFxsGW78wGHG2MS3PKXPUSmT1hyT4ViBOTxx9pMEvMeXnLg@mail.gmail.com>
 <MW4PR10MB5774E9E5E12DAF53DAFE7F96FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CANSoFxuNUd6Pe9rG9KD8UwpaQf=eKGEtisTHx596W4V6VO7EPQ@mail.gmail.com>

Hi Viktor,

Thanks for the response. I concur with all of your points below - nice
summary/analysis. Looking forward to this new use case.

-Archie

On Mon, Sep 23, 2024 at 10:38?AM Viktor Klang <viktor.klang at oracle.com>
wrote:

> Hi Archie!
>
> >I recently encountered a real-world use case for Stream Gatherers and
> thought I'd mention it (apologies if you've seen these ideas already).
> These might even be worth considering including as standard offerings.
>
> No need to preface your email with an apology ? I'm happy to get
> thoughts, feedback, and ideas!
>
> You have a pretty interesting use-case, and performing a "sub-group
> reorder" is an interesting use-case.
> Pulling on that string a bit more, it would seem like its primary
> use-cases would lie in scenarios where you're consuming things like data
> files (think CSVs etc where there's a predefined order/grouping to the
> entries) or consuming things like database results, would that be a fair
> characterization?
>
> Interestingly, one of the exercises I went through during the design of
> Gatherer was to reimplement the java.util.stream.Stream interface only
> using Gatherer and Collector, so I took a stab at things like sorted() etc.
> As is common in the situation of operating on top of pre-ordered data,
> parallelization tends to be costly to implement (either by having to forego
> it, or by needing to perform much of the operation in the finisher after
> aggregating elements in the integrator).
>
> Quickly thinking about the operation, I presume you'd need to be able to
> track the current "primary group", collect elements into something like an
> ArrayList, and upon switching to a new primary group, you sort the list
> according to the secondary group, emit all elements for as long as
> Downstream::push allows you to, clear the list, enqueue the new element
> which had the new primary group. Then in the finisher you perform the same
> operation, presuming that that's the signal that there's no more elements
> in the last primary group.
>
> But I think you can relax the requirement that the primary group must be
> Comparable, you only need to have a BiPredicate and test (prev, next) for
> sameness, and if you get false, you presume that `next` belongs to a new
> primary group. But since you're going to sort the group on the secondary,
> that'll need to be comparable.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Archie Cobbs <archie.cobbs at gmail.com>
> *Sent:* Friday, 20 September 2024 19:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Stream Gatherers (JEP 473) feedback
>
> Hi Viktor,
>
> I recently encountered a real-world use case for Stream Gatherers and
> thought I'd mention it (apologies if you've seen these ideas already).
> These might even be worth considering including as standard offerings.
>
> Motivating example: Suppose you have a large list of people sorted by
> LastName. Your goal is to print the list ordered by LastName, then by
> FirstName. The list is too large to re-sort the whole thing.
>
> Instead, you only need to "fixup" the ordering, by re-sorting just the
> groups of people with the same last name.
>
> If you happen to know that there are no more than 100 people with the
> exact same last nam, then one option would be a Gatherer that re-sorts a
> stream, but only up to some maximum window size (if two elements were out
> of order and separated by more than the window size, then sorted output
> would no longer be guaranteed).
>
> In the above example, you would set the window size to 100 and it might
> look something like this:
>
> listOfPeople.stream()   // sorted by lastName only
>   .gather(Gatherers.windowSort(100,
> Comparator.comparing(Person::lastName).thenComparing(Person::firstName)));
>
> Another (probably better) option would be a "secondary sort" Gatherer.
> This would take an already sorted stream and then apply a secondary sort.
> It would collect items having the same primary sort key (however many there
> were), and then re-sort those groups all at once using the secondary key:
>
> listOfPeople.stream()   // sorted by lastName only
>   .gather(Gatherers.secondarySort(Comparator.comparing(Person::lastName),
> Comparator.comparing(Person::firstName)));
>
> This kind of thing is common when querying a database that doesn't have
> the required composite index corresponding to a desired composite sort,
> e.g., there is an index on LastName and an index on FirstName, but no
> composite index on LastName+FirstName, etc.
>
>
-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/adf7efef/attachment.htm>

From jvernee at openjdk.org  Mon Sep 23 17:24:39 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 17:24:39 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <2e6M3FfXhdHJ1KtFnemnATPbuBsQ9a8BciCyWS83AUc=.1544705e-9fbc-4571-9f4b-8ede5070d56e@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <2e6M3FfXhdHJ1KtFnemnATPbuBsQ9a8BciCyWS83AUc=.1544705e-9fbc-4571-9f4b-8ede5070d56e@github.com>
Message-ID: <CeeKpkzwL8PMra8CdDN-t9sppL5QnCFLL25JrT4S5Gk=.97f77bd9-8353-44f3-ba44-efa039c778e2@github.com>

On Mon, 23 Sep 2024 16:40:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reword doce
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 225:
> 
>> 223:     // check elements are not all padding layouts and for trailing padding
>> 224:     private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {
>> 225:         if (!gl.memberLayouts().isEmpty() && gl.memberLayouts().stream().allMatch(e -> e instanceof PaddingLayout)) {
> 
> You have fixed the javadoc - but the check for `memberLayouts().isEmpty()` is still here?

This seems correct? We don't want to throw an exception for empty layouts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771824319

From mcimadamore at openjdk.org  Mon Sep 23 17:31:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 17:31:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <mzHDnS6FZX8Z4AqsyQFD-OJJsdhSOEVZkUbZNxNuF48=.c731d007-70b0-4982-9f90-96957e34d29d@github.com>

On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword doce

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21041#pullrequestreview-2322902337

From mcimadamore at openjdk.org  Mon Sep 23 17:31:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 17:31:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <CeeKpkzwL8PMra8CdDN-t9sppL5QnCFLL25JrT4S5Gk=.97f77bd9-8353-44f3-ba44-efa039c778e2@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <2e6M3FfXhdHJ1KtFnemnATPbuBsQ9a8BciCyWS83AUc=.1544705e-9fbc-4571-9f4b-8ede5070d56e@github.com>
 <CeeKpkzwL8PMra8CdDN-t9sppL5QnCFLL25JrT4S5Gk=.97f77bd9-8353-44f3-ba44-efa039c778e2@github.com>
Message-ID: <2bNArxV94hxOfGXaw-6b6o33X20hwCxWTRsGV-fn_qw=.e040f533-7586-4e08-a3ff-4f6a9cc200a8@github.com>

On Mon, 23 Sep 2024 17:22:02 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 225:
>> 
>>> 223:     // check elements are not all padding layouts and for trailing padding
>>> 224:     private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {
>>> 225:         if (!gl.memberLayouts().isEmpty() && gl.memberLayouts().stream().allMatch(e -> e instanceof PaddingLayout)) {
>> 
>> You have fixed the javadoc - but the check for `memberLayouts().isEmpty()` is still here?
>
> This seems correct? We don't want to throw an exception for empty layouts.

Whoops - you are right - I misread the condition

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1771831479

From iklam at openjdk.org  Mon Sep 23 17:33:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 23 Sep 2024 17:33:16 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v5]
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <0RDfQ1EaaC1aco8SnnkEiw7_TsCoDSS3TKT7Y0TdVvU=.b3e9c08e-1928-484f-956b-f9cc0bb8c5d7@github.com>

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @macarte comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20516/files
  - new: https://git.openjdk.org/jdk/pull/20516/files/64ff73fa..7b0d6f8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=03-04

  Stats: 21 lines in 4 files changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20516/head:pull/20516

PR: https://git.openjdk.org/jdk/pull/20516

From iklam at openjdk.org  Mon Sep 23 17:33:17 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 23 Sep 2024 17:33:17 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <tt1aTJvbJbIoaOpSzJlZjixS5PwCVh4dCHwlhlc-Yo8=.fa20b168-3575-4dfe-a31f-8332b5799f8d@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
 <tt1aTJvbJbIoaOpSzJlZjixS5PwCVh4dCHwlhlc-Yo8=.fa20b168-3575-4dfe-a31f-8332b5799f8d@github.com>
Message-ID: <yy2cD65hZGEIlHSgt7pzWcVpVciOTNm7iKYwHbqatvU=.cce10dd2-409e-4b23-b2bb-a2dc4a8bd8c9@github.com>

On Thu, 19 Sep 2024 21:43:54 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
>
> src/hotspot/share/cds/cds_globals.hpp line 102:
> 
>> 100:   /* See CDSConfig::check_flag_aliases().                               */  \
>> 101:                                                                             \
>> 102:   product(ccstr, AOTMode, nullptr,                                          \
> 
> you can replace nullptr with "auto" as that's the default, that would simplify some of the FLAG_IS_DEFAULT(AOTMode) || (strcmp(AOTMode, "auto") == 0 checks.  So you would now check strcmp(AOTMode, "auto") == 0 which I guess is slightly less performant (as FLAG_IS_DEFAULT is a cheap early out), however the current implementation means that the definition of the default value can spread across the codebase vs only being specified in cds_globals.hpp

If AOTMode has the "auto" value by default, that will be inconsistent if the JVM is started with old parameters like `-Xshare:dump` and `-Xshare:off`. I think it's better to leave it as null to avoid confusions (especially when running inside gdb, etc).

> src/hotspot/share/cds/metaspaceShared.cpp line 673:
> 
>> 671:   }
>> 672: 
>> 673:   if (AOTMode != nullptr && strcmp(AOTMode, "create") == 0) {
> 
> Would it be better to wrap this test in a CDSConfig::is_ method; which in turn can test the AOTMode FLAG directly or test (CDSConfig::is_dumping_static_archive() && !CDSConfig::is_old_cds_flags_used()), the point being that the meaning of the test is captured in the method name, but the test itself can change over time as needed

I added `CDSConfig::is_old_cds_flags_used()` and edited the comment. There's no need to check for `CDSConfig::is_dumping_static_archive()` as this function is called only when dumping the static archive.

(The "if" check may need further tweaking when merging into the Leyden repo, which has several modes of "static" archive dumping).

> test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java line 51:
> 
>> 49:     }
>> 50: 
>> 51:     static void positiveTests() throws Exception {
> 
> Missing a test for AOTMode=on

Added new test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1771832594
PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1771832798
PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1771832634

From iklam at openjdk.org  Mon Sep 23 17:33:17 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 23 Sep 2024 17:33:17 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <-GBifUfOpYOIAGRlwLOr_gYXgXsBsotpnyOAvSzVSKE=.49b786f2-f3e4-4f64-a933-e26ea12608f9@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
 <OI7ENirbce64xiExQ01VWaUtLaLbFGGuFSnxRVEUiWQ=.13eef949-e8af-4a8e-b3dc-e8112bae5061@github.com>
 <ldTVx6sJ5Ftd_GU1UVehsbpXIdtORVyr1kbgP_0kKEU=.1e679d6d-f69d-46c2-964c-df94869e3bfd@github.com>
 <-GBifUfOpYOIAGRlwLOr_gYXgXsBsotpnyOAvSzVSKE=.49b786f2-f3e4-4f64-a933-e26ea12608f9@github.com>
Message-ID: <WqTrtNKmoi4qUyG6_o3B3pcdJ00nIuyWLRhYg7udELU=.3e1a6d95-3979-4beb-ad5f-ed60d6beff92@github.com>

On Fri, 20 Sep 2024 01:17:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay both ways are valid, you could also remove the other "!= 0", the mixing was confusing
>
> Hotspot style rule is "no implicit booleans" so the check for `!= 0` should be used in all cases.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1771832719

From henryjen at openjdk.org  Mon Sep 23 17:37:50 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Sep 2024 17:37:50 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when extracting
 to not overwriting existing files
Message-ID: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>

This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

-------------

Commit messages:
 - Add simple test
 - Support legacy mode
 - 8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

Changes: https://git.openjdk.org/jdk/pull/21141/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335912
  Stats: 275 lines in 4 files changed: 274 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

PR: https://git.openjdk.org/jdk/pull/21141

From alanb at openjdk.org  Mon Sep 23 17:46:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 17:46:42 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v5]
In-Reply-To: <BpGfUItTokUXYypzo7ni4ZankbQqbbinPc8vQn4Mk58=.37a15287-7619-45b0-966d-45c8904cb59a@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <BpGfUItTokUXYypzo7ni4ZankbQqbbinPc8vQn4Mk58=.37a15287-7619-45b0-966d-45c8904cb59a@github.com>
Message-ID: <XQUr5i8DmbsK763qiAMero6C4XIrMArDaDBnRg_l0VA=.35adb8e2-2687-4ee6-9d71-57100a6ef257@github.com>

On Mon, 23 Sep 2024 16:29:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: Modify "More than one instance" paragraphs and convert to API notes

Thanks for the update, having this paragraph be an apiNote seems much better.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20320#pullrequestreview-2322930091

From jvernee at openjdk.org  Mon Sep 23 17:47:43 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Sep 2024 17:47:43 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <mAGAceidqagWb7Gftg-JncnM-MNJ9xG2y_Sf1PrSiIg=.003f0cc9-33ac-4620-8d9f-b30f105f6a20@github.com>

On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword doce

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21041#pullrequestreview-2322932510

From almatvee at openjdk.org  Mon Sep 23 17:59:37 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 23 Sep 2024 17:59:37 GMT
Subject: RFR: 8338918: Remove non translated file name from WinResources
 resource bundle [v3]
In-Reply-To: <OhSgZj-mWHfu2mkqST4xSBLsjBxF4TrsR8_eXAQo1VA=.e717baca-cbc4-41e6-be67-253866755444@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
 <OhSgZj-mWHfu2mkqST4xSBLsjBxF4TrsR8_eXAQo1VA=.e717baca-cbc4-41e6-be67-253866755444@github.com>
Message-ID: <OerrKkQtCJB43xBe1zxtNcmtp3YXCGjPOi8EACn7Fzg=.ec2bca39-9364-4534-b281-0ba7dfed5fa3@github.com>

On Fri, 20 Sep 2024 22:45:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix order of modifiers

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21100#pullrequestreview-2322963243

From bpb at openjdk.org  Mon Sep 23 18:00:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Sep 2024 18:00:37 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v5]
In-Reply-To: <XQUr5i8DmbsK763qiAMero6C4XIrMArDaDBnRg_l0VA=.35adb8e2-2687-4ee6-9d71-57100a6ef257@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <BpGfUItTokUXYypzo7ni4ZankbQqbbinPc8vQn4Mk58=.37a15287-7619-45b0-966d-45c8904cb59a@github.com>
 <XQUr5i8DmbsK763qiAMero6C4XIrMArDaDBnRg_l0VA=.35adb8e2-2687-4ee6-9d71-57100a6ef257@github.com>
Message-ID: <Q98iEo6UoEkbYYLa_DPjpaMrLUmPmdOP7ZaQ4KpCjnY=.e7e2b79b-9187-4573-ad26-a68a32a3e6be@github.com>

On Mon, 23 Sep 2024 17:43:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks for the update, having this paragraph be an apiNote seems much better.

You're welcome. I will update the CSR with this version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2368988258

From markus at headcrashing.eu  Mon Sep 23 18:05:59 2024
From: markus at headcrashing.eu (Markus Karg)
Date: Mon, 23 Sep 2024 20:05:59 +0200
Subject: AW: Range API
In-Reply-To: <CAL5bRt_d-SjK=nMJGGrLV15KuPDF7p=MYw0v9W6zTjNO1R616w@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <7528157.13866079.1727036234104.JavaMail.zimbra@univ-eiffel.fr>
 <CAL5bRt_d-SjK=nMJGGrLV15KuPDF7p=MYw0v9W6zTjNO1R616w@mail.gmail.com>
Message-ID: <006e01db0de3$3f1e4fd0$bd5aef70$@eu>

Why limiting Range to timespans? I once wrote Range<E>, see https://github.com/headcrashing/treasure-chest/blob/master/RangeClass/src/main/java/eu/headcrashing/java/util/Range.java. I could imagine this is useful

 

Von: core-libs-dev [mailto:core-libs-dev-retn at openjdk.org] Im Auftrag von Olexandr Rotan
Gesendet: Sonntag, 22. September 2024 22:53
An: Remi Forax
Cc: core-libs-dev
Betreff: Re: Range API

 

Hello! 
Thanks for your comments, they are valuable to me. I indeed intended to make Range immutable, if you noticed, in potential methods I listed extendTo and shrinkTo, which is kind of modified with-ers. But, it's indeed better to convert range to class and expose some methods to create bounded and unbounded ones.

The range pattern would be great to have, but unless there is some way to ger range object, there will not me a way to create range arithmetics. It would be better, in my opinion, to create member pattern inside Range class that can match it's type params. This may eliminate need for new syntax for range litterals and make feature more versatile.

Regarding the array return types, I specifically mentioned that this is the first thing up to change. Your point is completely valid, I will look into this issue as soon as possible.

I don't really understand the point about coupling different parts with an interface (future class I guess). Do you say that it is not desirable to have specialized versions of range such as timespan, and would prefer just one generic Range?

I appreciate all feedback you give. I will address your comments as soon as possible. I am new to API design, so I guess people won't go to hard on me. I hope that, iteratively, I could workout the API that would be a good match for JDK quality level.

Best regards

 

On Sun, Sep 22, 2024, 23:17 Remi Forax <forax at univ-mlv.fr> wrote:

Hello,

if we introduce a Range object, it will have to be an immutable class because otherwise any API that takes an interface Range as parameter will have to copy it into an immutable subclass first;

 

In term of design, coupling different parts of the JDK with an interface is not appealing to me, especially given that a Range is a very small object.

 

We (the amber EG) have talked about adding a way to do pattern matching using a Range with a special syntax like 1 .. 3, if we introduce such syntax, the runtime representation will be an immutable class an not an interface (think java.lang.String).

 

Your API is unsafe, you can not have a method that creates a Range<T>[] in a safe way, the combination of erasure + array covariant is nasty (at least until we have a way to create a read-only arrays).

 

regards,

R?mi

 


  _____  


From: "Olexandr Rotan" <rotanolexandr842 at gmail.com>
To: "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Sunday, September 22, 2024 9:01:47 PM
Subject: Range API

Hello everyone! I am writing here today to invite everyone to participate in the discussion regarding the Range APi proposal I have made into JDK. Here is the pull request link: https://github.com/openjdk/jdk/pull/21122, and PR text:





This pull request describes the methods of the Range<T> interface. The Range<T> interface represents a bounded or unbounded range. (From now on, range, span and interval are used interchangeably, but docs only use "range")


Goals:


?        Main goal. Standardization of the Range/Interval API: The primary objective of this effort is to provide a standardized interface for working with ranges or spans of time (or any ordered types). Many existing libraries offer their own custom implementations of ranges, and they differ in significant ways, making it harder to use and combine across different codebases. Standardization will ensure consistency, interoperability, and a more predictable interface across various contexts.

?        Versatile range operations: provide a comprehensive API for manipulating and querying ranges, especially those representing time periods or numerical intervals. The API simplifies common tasks like checking containment, overlaps, or adjacency between ranges.

?        Support for unbounded ranges: Unlike many existing libraries, which assume intervals are always bounded, this API aims to fully support unbounded intervals. Users will be able to define ranges with open starts or ends, making it suitable for temporal data that spans indefinitely in one direction, such as future projections or historical data with unknown starting points.

?        Performance efficiency: The API aims to provide optimized for performance implementation, that takes advantage of all possible simplifications and short-circuits.

?        Consistency with existing libraries: To aid adoption, the API should be familiar to developers who have used popular libraries like NodaTime, Joda-Time, Three-Ten Extra, and Boost Date_Time, but with enhancements for unbounded intervals, negative ranges (?), and optional return types instead of null values.


Non-Goals:


?        Handling complex data structures beyond smple ranges: This API is not intended to manage or represent complex data structures beyond ranges. For example, ranges that involve intricate internal states, like non-contiguous ranges (?) or ranges with multiple gaps, are out of scope.

?        Overly simplifying range types: While ease of use is a goal, its is not an aim to remove support for advanced cases like unbounded or negative ranges, even if this results in slightly more complex implementations. The API should not be skewed towards being purely a simple data structure for bounded ranges.

?        Application-specific logic: The API is meant to be domain-agnostic and general-purpose. It is not intended to allow to embed application-specific logic, such as calendar-based date manipulations or domain-specific business rules for interval comparison.

?        Replacing existing libraries: The goal is not to replace established libraries like Joda-Time or ThreeTen-Extra, but rather to augment these ideas with support for unbounded ranges and additional arithmetic operations. Although, it is a goal to provide interface that could exisiting libraries could easily retrofit into.


Motivation


The primary motivation behind standardizing the Range API is the lack of an established, universal interface for handling ranges or spans across various domains. Developers are often forced to work with different, incompatible range implementations across libraries or to re-implement common functionality themselves. This leads to redundant code, increased dependencies, and greater chances for errors.

In many software systems?whether in scheduling, auditing, access control, or financial services?ranges are used to represent periods of time, numerical intervals, or validity spans. Without a standardized API, developers must contend with diverse implementations that often differ in naming conventions, behavior, and supported features. These variations create unnecessary complexity, as developers must:

1.        Introduce additional dependencies: Many libraries provide similar functionality for ranges, but since they are not interchangeable, developers must often add extra dependencies to cover edge cases or specific use cases that are not available in a single library. This bloats the codebase and creates maintenance overhead.

2.        Re-implement common logic: In cases where no single library meets the required needs, developers are forced to write their own range-handling logic. This reinvention of basic operations such as intersection, union, or containment leads to redundancy, increased likelihood of bugs, and inconsistency in how ranges are handled across different parts of the code.

3.        Fragmentation across domains: Different libraries often define their own range concepts (e.g., for date-times, numbers, or general comparisons), which are rarely compatible with one another. This lack of compatibility makes integration between systems difficult, requiring custom adapters or conversions.

By defining a standard Range API, the goal is to:

*	Reduce the dependency footprint: A common, well-designed API for ranges would eliminate the need to import multiple libraries just to handle different types of ranges, reducing dependencies in projects and enhancing maintainability.
*	Simplify code and increase reusability: With a standardized interface, developers can write range-related code once and reuse it across projects and libraries, confident that the same semantics and operations will apply consistently.
*	Minimize developer errors: By providing a predictable and well-documented interface, the likelihood of misunderstandings or incorrect use of range operations will decrease. Developers can trust that operations like intersections, unions, and comparisons will behave consistently, regardless of the context.

In essence, the lack of standardization in range operations creates unnecessary complexity, fragmentation, and redundant effort. A standardized Range API would provide clarity, reduce the need for additional dependencies, and enable more efficient, reusable, and error-free code across different projects and domains.


Key API points


Support of unbounded intervals


API supports both one- and two-sided. Provided sample (draft) implementation for ChronoDateTime has 4 separate implementation for each type of ranges.


Alternatives


*	Many Libraries, like Luxon, C++ boost, NodaTime and many others, arguably the most, fo not explicitly support unbounded intervals. This reduces complexity of implementation, but takes away many possible optimization for edge-cases. Alternative they propose is to use Instant.MIN and Instant.MAX or similar to create unbounded-like intervals.


Support for negative intervals,


API supports both positive and negative and positive ranges. This is questionable and discussion is encouraged.


Advantages


*	Allows more flexible usage of API, which would be helpful for use cases like diagrams visualization.


Disadvantages


*	Dramatically increases amount of boilerplate code inside the implementations.
*	Makes behaviour of potential methods like boolean endsBefore(T t) unintuitive. Does this mean that end() is before that provided parameter, or latter of bounds (i.e. start() for negative range and end() for positive).
*	Limited usability scope. Most use cases would not benefit from possibility of negative ranges creation, but would have to suffer performance decrease.

In general, either there should be support for negative ranges, or ranges might be end-exclusve, but not two at the same time, as having them both together dramatically increases complexity.


Range is not Serializable


Currently ranges are not Serializable. This is due to difficulties regarding using non-serializable interfaces, like ChronoDateTIme  in sample implementation.


Alternatives


*	Restrict range type variable to implement Serializable. I see this option as undesiarable bacause of how much it narrows use of interface.


Current interface methods list is minimal


For now, API proposed contains minimal amount of methods that are used in range arithmetics. List of methods is supposed to change as discussion moves on.


Generic Range class vs Rnage interface + specific inmplementations


Currently, approach is to define interface and list of implementations.


Advantages


*	Ability to introduce specialized for type of range methods. For example, Timespan could have Duration toDuration() method, potential IntegerRange could have something like LongRange toLongRange() dur to limitations of comparability between classes. This would be impossible with structural class Range without declaring additional static utility methods.
*	Enhanced validation of annotaion targets as classes, unlike generics, arent erased.


Disadvantages


*	Increased amount of classes to maintain.
*	Additional considerations would be required before extending Range interface in case if hierarchy non-sealed to ensure backward compatibility.


API Description


NB: Since date ranges is supposed to be one of the most popular if not the most popular use case for range, date-time libraries were main reference for interface design.


  _____  


Section: Bounds


General notes


*	In Boost Date_Time (time_period.begin()), the start and end are always defined, meaning there is no concept of unbounded intervals. Similarly, some libraries like Chrono in Rust assume bounded intervals by default. In fact, only a few libraries expose trully unbound ranges. Although, while complexity of implementation is increased by this corner cases, thier performance also vastly increased by cutting amount of operations in each method at least in half (For two-way unbound interval, almost all operations return constnat value).


  _____  


T start()


Description:
Returns the start of the range. If the range is unbounded at the start, this method throws an UnsupportedOperationException. This can be preemptively checked using isBoundedAtStart().

Alternatives:

*	Method could return Optional<T> instead of throwing an exception. I see this two approaches roughly identical in terms of pros/cons score, so suggestions are much appreciated.


  _____  


T end()


Description:
Returns the end of the range. If the range is unbounded at the end, this method throws an UnsupportedOperationException. Use isBoundedAtEnd() to check if the range is bounded.

Alternatives:

*	Simallarly to start(), method could return Optional<T> instead of throwing an exception. I see this two approaches roughly identical in terms of pros/cons score, so suggestions are much appreciated.


  _____  


boolean isBoundedAtStart()


Description:
Returns true if the range is bounded at the start. If unbounded, it returns false, meaning calling start() will throw an UnsupportedOperationException.

Alternatives:

*	Joda-Time, NodaTime, Luxon, and Moment.js do not explicitly support unbounded intervals by default but can use null or special values to represent unbounded starts.
*	Boost Date_Time and Chrono don?t support unbounded ranges directly, so this method is unnecessary.


  _____  


boolean isBoundedAtEnd()


Description:
Returns true if the range is bounded at the end. A false value means the range is unbounded at the end, and calling end() will throw an UnsupportedOperationException.

Alternatives:

*	Similar to isBoundedAtStart(), most libraries don?t have built-in unbounded intervals, but the concept can be simulated using null, minimal/maximal possible value etc. Pros and cons were described in API notes.


  _____  


Section: boolean operations


boolean contains(T instant)


Description:
Returns true if the given instant falls within the start and end bounds of the range, otherwise returns false.

Similar Methods in other libraries:

*	NodaTime (Interval.Contains)
*	Joda-Time (Interval.contains)
*	Luxon (Interval.contains)
*	Boost Date_Time (time_period.contains())
*	And many others...

Differences with existing APIs:

*	Moment.js doesn?t provide a direct contains method but the moment-range plugin adds this functionality with range.contains().

Note: this method is present in most interval implementations. Terefore, I concider as basic and unremovable from the API.


  _____  


boolean overlaps(Range<? extends T> other)


Description:
Checks if the current range overlaps with another range. Returns true if the two ranges overlap, otherwise returns false.

Similar Methods in other libraries:

*	NodaTime (Interval.Overlaps)
*	Joda-Time (Interval.overlaps)
*	Luxon (Interval.overlaps)
*	Boost Date_Time (time_period.intersects())
*	And many others...

Differences with existing APIs:

*	Moment.js: The moment-range plugin provides a similar overlaps() method to check overlap.
*	Chrono relies on custom interval intersection logic.

Note: this method is present in most interval implementations. Terefore, I concider as basic and unremovable from the API.


  _____  


General notes on next two methods


Most of the libraries propose API like isBefore(T point) or do not provide methods like this at all. Since current implementation throws an exception if interval is not bounded, trivial check for isBefore could become 4-6 lines long. The question basically comes down to whether the Range class should be more data-structure-like or object-like. I would argue that at least isBefore(T moment) is required, especially since ranges can be negative currently. Existence of boolean isBefore(Range<? extends T> other)and similarisAfter` is up to discussion.


boolean isBefore(Range<? extends T> other)


Description:
Returns true if the current range is strictly before another range (i.e., ends before the other range starts).

Differences with other libraries:

*	NodaTime: You?d manually compare End of one interval with the Start of another.
*	Joda-Time: Manual comparison with Interval.getEnd() and Interval.getStart().
*	Boost Date_Time and Chrono would use custom logic to compare time_period or ranges of time, since they don?t have a direct equivalent of isBefore().

Alternatives

*	Most of the libraries propose API like isBefore(T point) or do not provide methods like this at all. Since current implementation throws an exception if interval is not bounded, trivial check for isBefore could become 4-6 lines long. The question basically comes down to whether the Range class should be more data-structure-like or object-like. I would argue that at least isBefore(T moment) is required, especially since ranges can be negative currently


  _____  


boolean isAfter(Range<? extends T> other)


Description:
Returns true if the current range is strictly after another range (i.e., starts after the other range ends).

*	Similar Methods:

*	Similar to isBefore(), manual comparisons are used in NodaTime, Joda-Time, and Luxon an others.


  _____  


boolean isBefore(T point)


Description:
Determines if the span ends before the given point. This is useful when you need to check whether a time span occurs entirely before a specific point.

Alternatives:

*	Method could be removed from APi at all, if Range is desired to be skewed towards being data structure.


  _____  


boolean isAfter(T point)


Description:
Determines if the span starts after the given point. This is useful when you need to check whether a time span occurs entirely after a specific point.

Alternatives:

*	Similarly to boolean isBefore(T point), method could be removed from APi at all, if Range is desired to be skewed towards being data structure.


  _____  


boolean isNegative()


Description:
Returns true if the start of the range is after the end, indicating a "negative" range.

Alternatives:

*	if concidered too niche, negatie timespans could be removed from model.

Note: this one is most questionable for me. Do we really need negative ranges? This is most entirely required in numeric ranges and diagrams, while introdcues huge complexity overhead for majority that doesnt need this feature. Negativity might be confusing for users. Would love to hear thoughs on this matter


  _____  


Section: Range arithmetics


Optional<Range<T>> intersection(Range<? extends T> other)


Description:
Returns the intersection of the current range with another range. If the ranges do not overlap, the result is an empty Optional. If they overlap, the intersection is returned.

Similar Methods:

*	NodaTime (Interval.Intersection())
*	Moment.js (via moment-range, range.intersect())
*	Joda-Time (Interval.overlap())
*	And many others...

Differences with existing APIs:

*	Boost Date_Time returns an empty time_period if no overlap exists, instead of an Optional. Some libraries return null (e.g., NodaTime).
*	Other libraries return null if intervals arent overlapping. This is undesrable, so optional returned instead.

Note: this method is present in most interval implementations. Terefore, I concider as basic and unremovable from the API.


  _____  


Range<T>[] union(Range<? extends T> other)


Description:
Returns the union of two ranges. If the ranges overlap, the result is a single combined range. If they do not overlap, the result is an array of two separate ranges.

Differences with existing APIs:

*	NodaTime and Joda-Time support similar logic using custom union handling.
*	Boost Date_Time has no built-in union() function but you can write custom logic to combine or separate intervals.

Note: Behaviour of this method is up to change. Currently, it returns array for maximal performance, but it can (and most likely should) be wrapped in some monadic class. As an alternative, there may be support for non-continuous ranges (ones with gaps inside them), then this method should return thise kind of range.


  _____  


Optional<Range<T>> gap(Range<? extends T> other)


Description:
Returns the gap between two ranges, if they do not overlap. If they overlap, the result is an empty Optional.

Differences with existing APIs:

*	NodaTime and Joda-Time support custom logic to calculate the gap using isBefore(), isAfter(), and manual calculations of the gap.
*	Other libraries return null if intervals are overlapping. This is undesrable, so optional returned instead.


  _____  


Section: potential methods


boolean isEmpty()


Description:
Determines if the range is "empty,"

Empty range is its own, separate type of range (basically opposite of unbounded range). There are many questions regrading this type of range. Is it bounded at start or end? If so, what should start() or end() return. Them throwing an exception would violate current contract between IsBoundedAtX() and 'x()` methods.

Advantages

*	Returning empty range instead of Optional might be more user-friendly

Disadvantages

*	One more concept in the API model
*	Corner case in IsBoundedAtX() and 'x()` contract.


Potential Methods for API Enhancement


In this section, we explore methods that could be added to the API, comparing them with similar functionality in popular time-related libraries. These methods enhance the versatility and clarity of the Range<T> implementation, especially in the context of temporal, numeric, and other domain-specific ranges. Some of these methods are inspired by well-established libraries, while others are novel suggestions.


  _____  


boolean encloses(Range<? extends T> other)


Description:
Checks whether the current range completely encloses another range, i.e., the other range starts after or at the start of the current range and ends before or at the end of the current range.

?        Similar Methods in Other Libraries:

*	NodaTime (Interval.ContainedBy)
*	Joda-Time (Interval.contains)
*	Luxon (Interval.contains)
*	Boost Date_Time (time_period.contains())

?        Differences with Existing APIs:

*	Some libraries handle encloses() and contains() in the same method. For clarity, this API can separate the two, where contains() is used for checking individual points and encloses() is for range-level comparison.


  _____  


boolean abuts(Range<? extends T> other)


Description:
Returns true if the current range abuts (i.e., touches but does not overlap) with another range. This method is useful when determining whether two ranges are adjacent but do not overlap.

?        Similar Methods in Other Libraries:

*	NodaTime (Interval.Abuts)

?        Alternatives:

*	Instead of this method, users could manually compare the end of one range and the start of another, but including abuts() in the API simplifies the logic and reduces error-prone comparisons.


  _____  


Range<T> extendTo(T point)


Description:
Returns a new range that extends the current range to include the given point. If the point is already within the range, it returns the current range. Otherwise, it extends either the start or end, depending on the point's position relative to the range.

?        Similar Methods in Other Libraries:

*	NodaTime and Joda-Time do not have explicit methods for this, but users can manipulate intervals manually.
*	Moment.js: The moment-ran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/5912cfbf/attachment-0001.htm>

From rotanolexandr842 at gmail.com  Mon Sep 23 18:10:40 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Mon, 23 Sep 2024 21:10:40 +0300
Subject: Range API
In-Reply-To: <CANSoFxtRywZSQtd+ACkUoHDvwTo6Ls851pn1zr0oKNBXQ-tDpw@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CANSoFxtRywZSQtd+ACkUoHDvwTo6Ls851pn1zr0oKNBXQ-tDpw@mail.gmail.com>
Message-ID: <CAL5bRt_GCbexQ7iiH0FefrnDSuDNTMypLdZq4si6pdaicAZCqw@mail.gmail.com>

Hello! Thanks for your comments

The start() and end() be should be specifiable as either inclusive or
> exclusive, otherwise open bounds are not possible. For example, how would
> one express the range of all Strings strictly less than "zzz"? (note every
> element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
> "zzz"). This is why for example NavigableSet.subSet() has parameters for
> that.


This has been addressed by modifying API today, now all types of ranges
support both exclusive and inclusive bounds.

I've never encountered a negative range and am skeptical that it would
> actually be useful. What's an example of a real-world use case? I don't see
> how they would help diagrams visualization other than maybe saving you a
> boolean, i.e., you could just use the normal range and draw the arrow the
> other way.


I guess this was my fault as I chose the wrong design perspective. I have
already commented on this pull request. Basically, I have some physics
background and I used to view ranges as vectors instead of scalars, so it
was just fluent to me in some way to allow negative ranges. Anyway, now
that I have received unanimous feedback regarding the requirement of
inclusive/exclusive bounds, and having both negative ranges and
different types of bounds just blows up the implementations, so negative
ranges were dropped.

In my experience, when you work with ranges you often also need to work
> with sets of ranges. If we had a Range class then it would be natural to
> also have a RangeSet class as well with union, intersection, difference,
> and ordered iteration operations, etc.


That is true. I saw high demand on it in comments, so now this is my second
priority in the list to develop Union type and common supertype for it and
Range (after making bounds compile-time checked so users don't have to
suffer exceptions if range does not have bound).

You are restricting to domains that implement Comparable, but this limits
> usefulness. For example, byte[] arrays are often ordered lexicographically
> as unsigned values and we want to work with ranges of byte[] arrays. It
> would be more general to allow supplying a Comparator (if needed, otherwise
> null). Then you would also want to expose this using a comparator() method
> (like SortedSet does). Note that Guava does not allow providing a
> Comparator so they voted the other way on this.


This would make range arithmetics tangled. What if you intersect ranges
with different comparators? What is the behaviour of gap and difference?
What if you want to unionize them? This most likely will lead to breach of
Union contract, which guarantees that ranges do not overlap. Even if users
pass a comparator to every operation, what will guarantee that end > start
for this comparator for both ranges? There are a lot of issues with this
initiative.

Guava has addressed this same problem; their approach worth reviewing:
> https://github.com/google/guava/wiki/RangesExplained


Thanks. I will look into it for references. To my shame, I haven't looked
into guava when designing the API, so this will be really useful.

Best regards

On Mon, Sep 23, 2024 at 5:10?AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Sun, Sep 22, 2024 at 2:03?PM Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
>> Hello everyone! I am writing here today to invite everyone to participate
>> in the discussion regarding the Range APi proposal I have made into JDK.
>>
>
> A few comments...
>
> Guava has addressed this same problem; their approach worth reviewing:
> https://github.com/google/guava/wiki/RangesExplained
>
> You are restricting to domains that implement Comparable, but this limits
> usefulness. For example, byte[] arrays are often ordered lexicographically
> as unsigned values and we want to work with ranges of byte[] arrays. It
> would be more general to allow supplying a Comparator (if needed, otherwise
> null). Then you would also want to expose this using a comparator() method
> (like SortedSet does). Note that Guava does not allow providing a
> Comparator so they voted the other way on this.
>
> The start() and end() be should be specifiable as either inclusive or
> exclusive, otherwise open bounds are not possible. For example, how would
> one express the range of all Strings strictly less than "zzz"? (note every
> element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
> "zzz"). This is why for example NavigableSet.subSet() has parameters for
> that.
>
> I've never encountered a negative range and am skeptical that it would
> actually be useful. What's an example of a real-world use case? I don't see
> how they would help diagrams visualization other than maybe saving you a
> boolean, i.e., you could just use the normal range and draw the arrow the
> other way.
>
> In my experience, when you work with ranges you often also need to work
> with sets of ranges. If we had a Range class then it would be natural to
> also have a RangeSet class as well with union, intersection, difference,
> and ordered iteration operations, etc.
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/1429ff9b/attachment.htm>

From rotanolexandr842 at gmail.com  Mon Sep 23 18:14:26 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Mon, 23 Sep 2024 21:14:26 +0300
Subject: Range API
In-Reply-To: <CAL5bRt_GCbexQ7iiH0FefrnDSuDNTMypLdZq4si6pdaicAZCqw@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CANSoFxtRywZSQtd+ACkUoHDvwTo6Ls851pn1zr0oKNBXQ-tDpw@mail.gmail.com>
 <CAL5bRt_GCbexQ7iiH0FefrnDSuDNTMypLdZq4si6pdaicAZCqw@mail.gmail.com>
Message-ID: <CAL5bRt-tRPwZdGBCnXMr_sL46YoPxwJRhstzEP-VUEPq+nMpXw@mail.gmail.com>

Hello, Markus.

API is not limited to timespans. It was a sample implementation for Range
interface back when it was not refactored into abstract class, which, by
the way, was removed from PR as for now.

My initial motivation was to provide a range for date and time values, so I
based general shape pretty heavily on the date time libraries.
Nevertheless, as you might see, API is type-agnostic, and one of the goals
is to make ranges specializable for different types (although this would
require additional research)

Best regards

On Mon, Sep 23, 2024 at 9:10?PM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> Hello! Thanks for your comments
>
> The start() and end() be should be specifiable as either inclusive or
>> exclusive, otherwise open bounds are not possible. For example, how would
>> one express the range of all Strings strictly less than "zzz"? (note every
>> element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
>> "zzz"). This is why for example NavigableSet.subSet() has parameters for
>> that.
>
>
> This has been addressed by modifying API today, now all types of ranges
> support both exclusive and inclusive bounds.
>
> I've never encountered a negative range and am skeptical that it would
>> actually be useful. What's an example of a real-world use case? I don't see
>> how they would help diagrams visualization other than maybe saving you a
>> boolean, i.e., you could just use the normal range and draw the arrow the
>> other way.
>
>
> I guess this was my fault as I chose the wrong design perspective. I have
> already commented on this pull request. Basically, I have some physics
> background and I used to view ranges as vectors instead of scalars, so it
> was just fluent to me in some way to allow negative ranges. Anyway, now
> that I have received unanimous feedback regarding the requirement of
> inclusive/exclusive bounds, and having both negative ranges and
> different types of bounds just blows up the implementations, so negative
> ranges were dropped.
>
> In my experience, when you work with ranges you often also need to work
>> with sets of ranges. If we had a Range class then it would be natural to
>> also have a RangeSet class as well with union, intersection, difference,
>> and ordered iteration operations, etc.
>
>
> That is true. I saw high demand on it in comments, so now this is my
> second priority in the list to develop Union type and common supertype for
> it and Range (after making bounds compile-time checked so users don't have
> to suffer exceptions if range does not have bound).
>
> You are restricting to domains that implement Comparable, but this limits
>> usefulness. For example, byte[] arrays are often ordered lexicographically
>> as unsigned values and we want to work with ranges of byte[] arrays. It
>> would be more general to allow supplying a Comparator (if needed, otherwise
>> null). Then you would also want to expose this using a comparator() method
>> (like SortedSet does). Note that Guava does not allow providing a
>> Comparator so they voted the other way on this.
>
>
> This would make range arithmetics tangled. What if you intersect ranges
> with different comparators? What is the behaviour of gap and difference?
> What if you want to unionize them? This most likely will lead to breach of
> Union contract, which guarantees that ranges do not overlap. Even if users
> pass a comparator to every operation, what will guarantee that end > start
> for this comparator for both ranges? There are a lot of issues with this
> initiative.
>
> Guava has addressed this same problem; their approach worth reviewing:
>> https://github.com/google/guava/wiki/RangesExplained
>
>
> Thanks. I will look into it for references. To my shame, I haven't looked
> into guava when designing the API, so this will be really useful.
>
> Best regards
>
> On Mon, Sep 23, 2024 at 5:10?AM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Sun, Sep 22, 2024 at 2:03?PM Olexandr Rotan <
>> rotanolexandr842 at gmail.com> wrote:
>>
>>> Hello everyone! I am writing here today to invite everyone to
>>> participate in the discussion regarding the Range APi proposal I have made
>>> into JDK.
>>>
>>
>> A few comments...
>>
>> Guava has addressed this same problem; their approach worth reviewing:
>> https://github.com/google/guava/wiki/RangesExplained
>>
>> You are restricting to domains that implement Comparable, but this limits
>> usefulness. For example, byte[] arrays are often ordered lexicographically
>> as unsigned values and we want to work with ranges of byte[] arrays. It
>> would be more general to allow supplying a Comparator (if needed, otherwise
>> null). Then you would also want to expose this using a comparator() method
>> (like SortedSet does). Note that Guava does not allow providing a
>> Comparator so they voted the other way on this.
>>
>> The start() and end() be should be specifiable as either inclusive or
>> exclusive, otherwise open bounds are not possible. For example, how would
>> one express the range of all Strings strictly less than "zzz"? (note every
>> element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
>> "zzz"). This is why for example NavigableSet.subSet() has parameters for
>> that.
>>
>> I've never encountered a negative range and am skeptical that it would
>> actually be useful. What's an example of a real-world use case? I don't see
>> how they would help diagrams visualization other than maybe saving you a
>> boolean, i.e., you could just use the normal range and draw the arrow the
>> other way.
>>
>> In my experience, when you work with ranges you often also need to work
>> with sets of ranges. If we had a Range class then it would be natural to
>> also have a RangeSet class as well with union, intersection, difference,
>> and ordered iteration operations, etc.
>>
>> -Archie
>>
>> --
>> Archie L. Cobbs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/6a055a97/attachment-0001.htm>

From henryjen at openjdk.org  Mon Sep 23 18:25:59 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Sep 2024 18:25:59 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v2]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <jKeJSjGa6NgMAe1GsOCg_M5orSZGRckaOCKSGOz6qdQ=.6ffd5298-e851-4f19-b5a5-14d458ae0222@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Fix the long option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21141/files
  - new: https://git.openjdk.org/jdk/pull/21141/files/ecef7aaf..f03956a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

PR: https://git.openjdk.org/jdk/pull/21141

From sviswanathan at openjdk.org  Mon Sep 23 18:27:45 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 23 Sep 2024 18:27:45 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v12]
In-Reply-To: <YTuwAMwWzDUteOb6zkIIPfoVp2IBCU2BLjJGMdN1q20=.a0cb7d5f-6ec3-4cca-9c2c-6439cee6180c@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <YTuwAMwWzDUteOb6zkIIPfoVp2IBCU2BLjJGMdN1q20=.a0cb7d5f-6ec3-4cca-9c2c-6439cee6180c@github.com>
Message-ID: <sgggqL5KqFHVh__vHk7Fnb3qWaiUHXiUQfc5uglgMEQ=.17ebeb05-eeca-44ec-8c0f-22a7aa2a9a66@github.com>

On Wed, 18 Sep 2024 07:21:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporating review and documentation suggestions.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2600:

> 2598:         assert ((vlen & (vlen -1)) == 0);
> 2599:         int twoVectorLenMask = (vlen << 1) - 1;
> 2600:         ByteVector wrapped_indexes = this.lanewise(VectorOperators.AND, twoVectorLenMask);

This assert and the following AND forcing power of two vector length seems out of place in Java code.  You could move the wrapping within the selectFromTwoVectorOp on similar lines as the PR #20634.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1771898190

From brian.goetz at oracle.com  Mon Sep 23 18:47:49 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 23 Sep 2024 14:47:49 -0400
Subject: Range API
In-Reply-To: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
Message-ID: <9f7972fa-1e50-4c5d-b8cb-b9af5b29e20f@oracle.com>

This is a nice start.? I'd like to add a few comments to help set 
expectations and to guide future explorations here.

Starting with a "main goal" of "putting it in the JDK" is putting the 
cart before the horse.? The main goal should be to solve the problem 
well enough, for a broad enough variety of uses, that it might be 
_considered as a candidate for the JDK_ (possibly with some additional 
work), but it should stand well enough on its own.? (The Joda Time -> 
java.util.time transition is a good example of doing this right.)? Build 
a good thing first, then let's have a conversation about whether it 
belongs in the JDK.

Another consideration I'd like to put on the table is: can it be a value 
type?? Because an immutable range (and we wouldn't consider anything 
else) is an ideal candidate for being a value.? (This is one of many "is 
it going where the language is going" questions; I'll keep the rest of 
those to myself for now.)

As has been pointed out already, one would prefer to use a Comparator as 
a witness to ordering rather than the much weaker Comparable.

I would want to see Range implement Iterable (yes, I understand this 
rules out some possible types of ranges), as iterating over the elements 
of a range is one of the most likely operations.

I think the algebraic operations as you've proposed them (union, 
intersection, etc) are a bit of a mess, union especially.





On 9/22/2024 3:01 PM, Olexandr Rotan wrote:
> Hello everyone! I am writing here today to invite everyone to 
> participate in the discussion regarding the Range APi proposal I have 
> made into JDK. Here is the pull request link: 
> https://github.com/openjdk/jdk/pull/21122, and PR text:
>
> This pull request describes the methods of the |Range<T>|?interface. 
> The |Range<T>|?interface represents a bounded or unbounded range. 
> (From now on, range, span and interval are used interchangeably, but 
> docs only use "range")
>
>
>       Goals:
>
>  *
>
>     *Main goal. Standardization of the Range/Interval API:*?The
>     primary objective of this effort is to provide a standardized
>     interface for working with ranges or spans of time (or any ordered
>     types). Many existing libraries offer their own custom
>     implementations of ranges, and they differ in significant ways,
>     making it harder to use and combine across different codebases.
>     Standardization will ensure consistency, interoperability, and a
>     more predictable interface across various contexts.
>
>  *
>
>     *Versatile range operations:*?provide a comprehensive API for
>     manipulating and querying ranges, especially those representing
>     time periods or numerical intervals. The API simplifies common
>     tasks like checking containment, overlaps, or adjacency between
>     ranges.
>
>  *
>
>     *Support for unbounded ranges:*?Unlike many existing libraries,
>     which assume intervals are always bounded, this API aims to fully
>     support unbounded intervals. Users will be able to define ranges
>     with open starts or ends, making it suitable for temporal data
>     that spans indefinitely in one direction, such as future
>     projections or historical data with unknown starting points.
>
>  *
>
>     *Performance efficiency:*?The API aims to provide optimized for
>     performance implementation, that takes advantage of all possible
>     simplifications and short-circuits.
>
>  *
>
>     *Consistency with existing libraries:*?To aid adoption, the API
>     should be familiar to developers who have used popular libraries
>     like NodaTime, Joda-Time, Three-Ten Extra, and Boost Date_Time,
>     but with enhancements for unbounded intervals, negative ranges
>     (?), and optional return types instead of null values.
>
>
>       Non-Goals:
>
>  *
>
>     *Handling complex data structures beyond smple ranges:*?This API
>     is not intended to manage or represent complex data structures
>     beyond ranges. For example, ranges that involve intricate internal
>     states, like non-contiguous ranges (?) or ranges with multiple
>     gaps, are out of scope.
>
>  *
>
>     *Overly simplifying range types:*?While ease of use is a goal, its
>     is not an aim to remove support for advanced cases like unbounded
>     or negative ranges, even if this results in slightly more complex
>     implementations. The API should not be skewed towards being purely
>     a simple data structure for bounded ranges.
>
>  *
>
>     *Application-specific logic:*?The API is meant to be
>     domain-agnostic and general-purpose. It is not intended to allow
>     to embed application-specific logic, such as calendar-based date
>     manipulations or domain-specific business rules for interval
>     comparison.
>
>  *
>
>     *Replacing existing libraries:*?The goal is not to replace
>     established libraries like Joda-Time or ThreeTen-Extra, but rather
>     to augment these ideas with support for unbounded ranges and
>     additional arithmetic operations. Although, it is a goal to
>     provide interface that could exisiting libraries could easily
>     retrofit into.
>
>
>       Motivation
>
> The primary motivation behind standardizing the |Range|?API is the 
> *lack of an established, universal interface*?for handling ranges or 
> spans across various domains. Developers are often forced to work with 
> different, incompatible range implementations across libraries or to 
> re-implement common functionality themselves. This leads to redundant 
> code, increased dependencies, and greater chances for errors.
>
> In many software systems?whether in scheduling, auditing, access 
> control, or financial services?ranges are used to represent periods of 
> time, numerical intervals, or validity spans. Without a standardized 
> API, developers must contend with diverse implementations that often 
> differ in naming conventions, behavior, and supported features. These 
> variations create unnecessary complexity, as developers must:
>
> 1.
>
>     *Introduce additional dependencies*: Many libraries provide
>     similar functionality for ranges, but since they are not
>     interchangeable, developers must often add extra dependencies to
>     cover edge cases or specific use cases that are not available in a
>     single library. This bloats the codebase and creates maintenance
>     overhead.
>
> 2.
>
>     *Re-implement common logic*: In cases where no single library
>     meets the required needs, developers are forced to write their own
>     range-handling logic. This reinvention of basic operations such as
>     intersection, union, or containment leads to redundancy, increased
>     likelihood of bugs, and inconsistency in how ranges are handled
>     across different parts of the code.
>
> 3.
>
>     *Fragmentation across domains*: Different libraries often define
>     their own range concepts (e.g., for date-times, numbers, or
>     general comparisons), which are rarely compatible with one
>     another. This lack of compatibility makes integration between
>     systems difficult, requiring custom adapters or conversions.
>
> By defining a standard |Range|?API, the goal is to:
>
>   * *Reduce the dependency footprint:*?A common, well-designed API for
>     ranges would eliminate the need to import multiple libraries just
>     to handle different types of ranges, reducing dependencies in
>     projects and enhancing maintainability.
>   * *Simplify code and increase reusability:*?With a standardized
>     interface, developers can write range-related code once and reuse
>     it across projects and libraries, confident that the same
>     semantics and operations will apply consistently.
>   * *Minimize developer errors:*?By providing a predictable and
>     well-documented interface, the likelihood of misunderstandings or
>     incorrect use of range operations will decrease. Developers can
>     trust that operations like intersections, unions, and comparisons
>     will behave consistently, regardless of the context.
>
> In essence, the lack of standardization in range operations creates 
> unnecessary complexity, fragmentation, and redundant effort. A 
> standardized |Range|?API would provide clarity, reduce the need for 
> additional dependencies, and enable more efficient, reusable, and 
> error-free code across different projects and domains.
>
>
>   Key API points
>
>
>     Support of unbounded intervals
>
> API supports both one- and two-sided. Provided sample (draft) 
> implementation for|ChronoDateTime|?has 4 separate implementation for 
> each type of ranges.
>
>
>       Alternatives
>
>   * Many Libraries, like Luxon, C++ boost, NodaTime and many others,
>     arguably the most, fo not explicitly support unbounded intervals.
>     This reduces complexity of implementation, but takes away many
>     possible optimization for edge-cases. Alternative they propose is
>     to use Instant.MIN and Instant.MAX or similar to create
>     unbounded-like intervals.
>
>
>     Support for negative intervals,
>
> API supports both positive and negative and positive ranges. This is 
> questionable and discussion is encouraged.
>
>
>       Advantages
>
>   * Allows more flexible usage of API, which would be helpful for use
>     cases like diagrams visualization.
>
>
>       Disadvantages
>
>   * Dramatically increases amount of boilerplate code inside the
>     implementations.
>   * Makes behaviour of potential methods like |boolean endsBefore(T t)
>     |unintuitive. Does this mean that end() is before that provided
>     parameter, or latter of bounds (i.e. |start()|?for negative range
>     and |end()|?for positive).
>   * Limited usability scope. Most use cases would not benefit from
>     possibility of negative ranges creation, but would have to suffer
>     performance decrease.
>
> In general, either there should be support for negative ranges, or 
> ranges might be end-exclusve, but not two at the same time, as having 
> them both together dramatically increases complexity.
>
>
>     |Range|?is not |Serializable|
>
> Currently ranges are not|Serializable|. This is due to difficulties 
> regarding using non-serializable interfaces, like |ChronoDateTIme |?in 
> sample implementation.
>
>
>       Alternatives
>
>   * Restrict range type variable to implement |Serializable|. I see
>     this option as undesiarable bacause of how much it narrows use of
>     interface.
>
>
>     Current interface methods list is minimal
>
> For now, API proposed contains minimal amount of methods that are used 
> in range arithmetics. List of methods is supposed to change as 
> discussion moves on.
>
>
>     Generic Range class vs Rnage interface + specific inmplementations
>
> Currently, approach is to define interface and list of implementations.
>
>
>       Advantages
>
>   * Ability to introduce specialized for type of range methods. For
>     example, |Timespan|?could have |Duration toDuration()|?method,
>     potential |IntegerRange|?could have something like |LongRange
>     toLongRange()|?dur to limitations of comparability between
>     classes. This would be impossible with structural class Range
>     without declaring additional static utility methods.
>   * Enhanced validation of annotaion targets as classes, unlike
>     generics, arent erased.
>
>
>       Disadvantages
>
>   * Increased amount of classes to maintain.
>   * Additional considerations would be required before extending Range
>     interface in case if hierarchy non-sealed to ensure backward
>     compatibility.
>
>
>   API Description
>
>
>       NB: Since date ranges is supposed to be one of the most popular
>       if not the most popular use case for range, date-time libraries
>       were main reference for interface design.
>
> ------------------------------------------------------------------------
>
>
>     Section: Bounds
>
>
>       General notes
>
>   * In *Boost Date_Time*?(|time_period.begin()|), the start and end
>     are always defined, meaning there is no concept of unbounded
>     intervals. Similarly, some libraries like *Chrono*?in Rust assume
>     bounded intervals by default. In fact, only a few libraries expose
>     trully unbound ranges. Although, while complexity of
>     implementation is increased by this corner cases, thier
>     performance also vastly increased by cutting amount of operations
>     in each method at least in half (For two-way unbound interval,
>     almost all operations return constnat value).
>
> ------------------------------------------------------------------------
>
>
>       |T start()|
>
> *Description:*
> Returns the start of the range. If the range is unbounded at the 
> start, this method throws an |UnsupportedOperationException|. This can 
> be preemptively checked using |isBoundedAtStart()|.
>
> *Alternatives:*
>
>   * Method could return |Optional<T>|?instead of throwing an
>     exception. I see this two approaches roughly identical in terms of
>     pros/cons score, so suggestions are much appreciated.
>
> ------------------------------------------------------------------------
>
>
>       |T end()|
>
> *Description*:
> Returns the end of the range. If the range is unbounded at the end, 
> this method throws an |UnsupportedOperationException|. Use 
> |isBoundedAtEnd()|?to check if the range is bounded.
>
> *Alternatives:*
>
>   * Simallarly to start(), method could return |Optional<T>|?instead
>     of throwing an exception. I see this two approaches roughly
>     identical in terms of pros/cons score, so suggestions are much
>     appreciated.
>
> ------------------------------------------------------------------------
>
>
>       |boolean isBoundedAtStart()|
>
> *Description*:
> Returns |true|?if the range is bounded at the start. If unbounded, it 
> returns |false|, meaning calling |start()|?will throw an 
> |UnsupportedOperationException|.
>
> *Alternatives*:
>
>   * *Joda-Time*, *NodaTime*, *Luxon*, and *Moment.js*?do not
>     explicitly support unbounded intervals by default but can use
>     |null|?or special values to represent unbounded starts.
>   * *Boost Date_Time*?and *Chrono*?don?t support unbounded ranges
>     directly, so this method is unnecessary.
>
> ------------------------------------------------------------------------
>
>
>       |boolean isBoundedAtEnd()|
>
> *Description*:
> Returns |true|?if the range is bounded at the end. A false value means 
> the range is unbounded at the end, and calling |end()|?will throw an 
> |UnsupportedOperationException|.
>
> *Alternatives*:
>
>   * Similar to |isBoundedAtStart()|, most libraries don?t have
>     built-in unbounded intervals, but the concept can be simulated
>     using |null|, minimal/maximal possible value etc. Pros and cons
>     were described in API notes.
>
> ------------------------------------------------------------------------
>
>
>     Section: boolean operations
>
>
>       |boolean contains(T instant)|
>
> *Description*:
> Returns |true|?if the given |instant|?falls within the start and end 
> bounds of the range, otherwise returns |false|.
>
> *Similar Methods in other libraries*:
>
>   * *NodaTime (|Interval.Contains|)*
>   * *Joda-Time (|Interval.contains|)*
>   * *Luxon (|Interval.contains|)*
>   * *Boost Date_Time (|time_period.contains()|)*
>   * And many others...
>
> *Differences with existing APIs*:
>
>   * *Moment.js*?doesn?t provide a direct |contains|?method but the
>     |moment-range|?plugin adds this functionality with |range.contains()|.
>
> *Note*: this method is present in most interval implementations. 
> Terefore, I concider as basic and unremovable from the API.
>
> ------------------------------------------------------------------------
>
>
>       |boolean overlaps(Range<? extends T> other)|
>
> *Description*:
> Checks if the current range overlaps with another range. Returns 
> |true|?if the two ranges overlap, otherwise returns |false|.
>
> *Similar Methods in other libraries*:
>
>   * *NodaTime (|Interval.Overlaps|)*
>   * *Joda-Time (|Interval.overlaps|)*
>   * *Luxon (|Interval.overlaps|)*
>   * *Boost Date_Time (|time_period.intersects()|)*
>   * And many others...
>
> *Differences with existing APIs*:
>
>   * *Moment.js*: The |moment-range|?plugin provides a similar
>     |overlaps()|?method to check overlap.
>   * *Chrono*?relies on custom interval intersection logic.
>
> *Note*: this method is present in most interval implementations. 
> Terefore, I concider as basic and unremovable from the API.
>
> ------------------------------------------------------------------------
>
>
>       General notes on next two methods
>
> Most of the libraries propose API like |isBefore(T point)|?or do not 
> provide methods like this at all. Since current implementation throws 
> an exception if interval is not bounded, trivial check for 
> |isBefore|?could become 4-6 lines long. The question basically comes 
> down to whether the Range class should be more data-structure-like or 
> object-like. I would argue that at least |isBefore(T moment)|?is 
> required, especially since ranges can be negative currently. Existence 
> of boolean isBefore(Range<? extends T> other)|and similar|isAfter` is 
> up to discussion.
>
>
>       |boolean isBefore(Range<? extends T> other)|
>
> *Description*:
> Returns |true|?if the current range is strictly before another range 
> (i.e., ends before the other range starts).
>
> *Differences with other libraries*:
>
>   * *NodaTime*: You?d manually compare |End|?of one interval with the
>     |Start|?of another.
>   * *Joda-Time*: Manual comparison with |Interval.getEnd()|?and
>     |Interval.getStart()|.
>   * *Boost Date_Time*?and *Chrono*?would use custom logic to compare
>     |time_period|?or ranges of time, since they don?t have a direct
>     equivalent of |isBefore()|.
>
> *Alternatives*
>
>   * Most of the libraries propose API like |isBefore(T point)|?or do
>     not provide methods like this at all. Since current implementation
>     throws an exception if interval is not bounded, trivial check for
>     |isBefore|?could become 4-6 lines long. The question basically
>     comes down to whether the Range class should be more
>     data-structure-like or object-like. I would argue that at least
>     |isBefore(T moment)|?is required, especially since ranges can be
>     negative currently
>
> ------------------------------------------------------------------------
>
>
>       |boolean isAfter(Range<? extends T> other)|
>
> *Description*:
> Returns |true|?if the current range is strictly after another range 
> (i.e., starts after the other range ends).
>
>   * *Similar Methods*:
>       o Similar to |isBefore()|, manual comparisons are used in
>         *NodaTime*, *Joda-Time*, and *Luxon*?an others.
>
> ------------------------------------------------------------------------
>
>
>       |boolean isBefore(T point)|
>
> *Description:*
> Determines if the span ends before the given point. This is useful 
> when you need to check whether a time span occurs entirely before a 
> specific point.
>
> *Alternatives*:
>
>   * Method could be removed from APi at all, if Range is desired to be
>     skewed towards being data structure.
>
> ------------------------------------------------------------------------
>
>
>       |boolean isAfter(T point)|
>
> *Description:*
> Determines if the span starts after the given point. This is useful 
> when you need to check whether a time span occurs entirely after a 
> specific point.
>
> *Alternatives*:
>
>   * Similarly to |boolean isBefore(T point)|, method could be removed
>     from APi at all, if Range is desired to be skewed towards being
>     data structure.
>
> ------------------------------------------------------------------------
>
>
>       |boolean isNegative()|
>
> *Description*:
> Returns |true|?if the start of the range is after the end, indicating 
> a "negative" range.
>
> *Alternatives:*
>
>   * if concidered too niche, negatie timespans could be removed from
>     model.
>
> *Note:*?this one is most questionable for me. Do we really need 
> negative ranges? This is most entirely required in numeric ranges and 
> diagrams, while introdcues huge complexity overhead for majority that 
> doesnt need this feature. Negativity might be confusing for users. 
> Would love to hear thoughs on this matter
>
> ------------------------------------------------------------------------
>
>
>     Section: Range arithmetics
>
>
>       |Optional<Range<T>> intersection(Range<? extends T> other)|
>
> *Description*:
> Returns the intersection of the current range with another range. If 
> the ranges do not overlap, the result is an empty |Optional|. If they 
> overlap, the intersection is returned.
>
> *Similar Methods*:
>
>   * *NodaTime (|Interval.Intersection()|)*
>   * *Moment.js (via |moment-range|, |range.intersect()|)*
>   * *Joda-Time (|Interval.overlap()|)*
>   * And many others...
>
> *Differences with existing APIs*:
>
>   * *Boost Date_Time*?returns an empty |time_period|?if no overlap
>     exists, instead of an |Optional|. Some libraries return
>     |null|?(e.g., *NodaTime*).
>   * Other libraries return null if intervals arent overlapping. This
>     is undesrable, so optional returned instead.
>
> *Note*: this method is present in most interval implementations. 
> Terefore, I concider as basic and unremovable from the API.
>
> ------------------------------------------------------------------------
>
>
>       |Range<T>[] union(Range<? extends T> other)|
>
> *Description*:
> Returns the union of two ranges. If the ranges overlap, the result is 
> a single combined range. If they do not overlap, the result is an 
> array of two separate ranges.
>
> *Differences with existing APIs*:
>
>   * *NodaTime*?and *Joda-Time*?support similar logic using custom
>     union handling.
>   * *Boost Date_Time*?has no built-in |union()|?function but you can
>     write custom logic to combine or separate intervals.
>
> *Note*: Behaviour of this method is up to change. Currently, it 
> returns array for maximal performance, but it can (and most likely 
> should) be wrapped in some monadic class. As an alternative, there may 
> be support for non-continuous ranges (ones with gaps inside them), 
> then this method should return thise kind of range.
>
> ------------------------------------------------------------------------
>
>
>       |Optional<Range<T>> gap(Range<? extends T> other)|
>
> *Description*:
> Returns the gap between two ranges, if they do not overlap. If they 
> overlap, the result is an empty |Optional|.
>
> *Differences with existing APIs*:
>
>   * *NodaTime*?and *Joda-Time*?support custom logic to calculate the
>     gap using |isBefore()|, |isAfter()|, and manual calculations of
>     the gap.
>   * Other libraries return null if intervals are overlapping. This is
>     undesrable, so optional returned instead.
>
> ------------------------------------------------------------------------
>
>
>     Section: potential methods
>
>
>       |boolean isEmpty()|
>
> *Description:*
> Determines if the range is "empty,"
>
> Empty range is its own, separate type of range (basically opposite of 
> unbounded range). There are many questions regrading this type of 
> range. Is it bounded at start or end? If so, what should |start()|?or 
> |end()|?return. Them throwing an exception would violate current 
> contract between |IsBoundedAtX()|?and 'x()` methods.
>
> *Advantages*
>
>   * Returning empty range instead of Optional might be more user-friendly
>
> *Disadvantages*
>
>   * One more concept in the API model
>   * Corner case in |IsBoundedAtX()|?and 'x()` contract.
>
>
>       Potential Methods for API Enhancement
>
> In this section, we explore methods that could be added to the API, 
> comparing them with similar functionality in popular time-related 
> libraries. These methods enhance the versatility and clarity of the 
> |Range<T>|?implementation, especially in the context of temporal, 
> numeric, and other domain-specific ranges. Some of these methods are 
> inspired by well-established libraries, while others are novel 
> suggestions.
>
> ------------------------------------------------------------------------
>
>
>       |boolean encloses(Range<? extends T> other)|
>
> *Description*:
> Checks whether the current range completely encloses another range, 
> i.e., the other range starts after or at the start of the current 
> range and ends before or at the end of the current range.
>
>  *
>
>     *Similar Methods in Other Libraries*:
>
>       o *NodaTime (|Interval.ContainedBy|)*
>       o *Joda-Time (|Interval.contains|)*
>       o *Luxon (|Interval.contains|)*
>       o *Boost Date_Time (|time_period.contains()|)*
>  *
>
>     *Differences with Existing APIs*:
>
>       o Some libraries handle |encloses()|?and |contains()|?in the
>         same method. For clarity, this API can separate the two, where
>         |contains()|?is used for checking individual points and
>         |encloses()|?is for range-level comparison.
>
> ------------------------------------------------------------------------
>
>
>       |boolean abuts(Range<? extends T> other)|
>
> *Description*:
> Returns |true|?if the current range abuts (i.e., touches but does not 
> overlap) with another range. This method is useful when determining 
> whether two ranges are adjacent but do not overlap.
>
>  *
>
>     *Similar Methods in Other Libraries*:
>
>       o *NodaTime (|Interval.Abuts|)*
>  *
>
>     *Alternatives*:
>
>       o Instead of this method, users could manually compare the
>         |end|?of one range and the |start|?of another, but including
>         |abuts()|?in the API simplifies the logic and reduces
>         error-prone comparisons.
>
> ------------------------------------------------------------------------
>
>
>       |Range<T> extendTo(T point)|
>
> *Description*:
> Returns a new range that extends the current range to include the 
> given point. If the point is already within the range, it returns the 
> current range. Otherwise, it extends either the start or end, 
> depending on the point's position relative to the range.
>
>  *
>
>     *Similar Methods in Other Libraries*:
>
>       o *NodaTime*?and *Joda-Time*?do not have explicit methods for
>         this, but users can manipulate intervals manually.
>       o *Moment.js*: The |moment-range|?plugin offers similar logic
>         via manual adjustments to the range.
>  *
>
>     *Advantages*:
>
>       o In contrast to manual adjustment, this method automates the
>         process of extending ranges, which can be useful in situations
>         where ranges need to be dynamically modified over time (e.g.,
>         expanding time intervals in streaming data).
>
> *Alternatives*:
>
>   * Users could manually adjust the range using |start()|?and
>     |end()|?"withers", but an explicit |extendTo()|?method offers a
>     more intuitive, built-in approach
>
> ------------------------------------------------------------------------
>
>
>       |Range<T> shrinkTo(T point)|
>
> *Description*:
> Returns a new range that shrinks the current range to exclude the 
> given point, if possible. If the point is within the range, the range 
> is modified so that it no longer includes the point. This is useful 
> for splitting ranges or excluding unwanted time periods or values.
>
>   * *Similar Methods in Other Libraries*:
>     No major time libraries provide a direct equivalent to this
>     functionality, although similar operations can be manually
>     performed by manipulating |start|?and |end|.
>
> *Alternatives*:
>
>   * Similarly to |extendTo|, users could manually adjust the range
>     using |start()|?and |end()|?"withers", but an explicit
>     |shrinkTo()|?method offers a more intuitive, built-in approach.
>
> ------------------------------------------------------------------------
>
>
>       |Range<T>[] difference(Range<? extends T> other)|
>
> *Description*:
> Returns the difference between the current range and another range 
> (XOR operations). If the ranges overlap, the result is a new range or 
> two ranges representing the non-overlapping portions. If the ranges do 
> not overlap, the result is the current range.
>
> *Adavntages*:
>
>   * This method simplifies computing the difference between two
>     ranges, reducing the need for manual boundary comparisons.
>   * Completes set of methods required for ranges arithmetics
>
> *Disdavntages*:
>
>   * THis method is inverse of |union(Range<? extends T> other)|, so it
>     has same design problems as union.
>
> ------------------------------------------------------------------------
>
>
>       |Range<T> clamp(Range<? extends T> bounds)|
>
> *Description*:
> Clamps the current range to fit within the specified bounds. If the 
> current range extends outside of the bounds, it is shortened to fit 
> within the bounds. If the range already fits within the bounds, it is 
> returned unchanged.
>
> *Advantages*:
>
>   * This method streamlines the process of adjusting a range to a set
>     of bounds, which is especially useful in time-based operations
>     where ranges must be constrained within specific periods (e.g.,
>     scheduling).
>
> ------------------------------------------------------------------------
>
>
>       |boolean isContiguousWith(Range<? extends T> other)|
>
> *Description*:
> Determines if the current range is contiguous with another range, 
> meaning that the two ranges touch or overlap without leaving any gaps. 
> This is particularly useful when combining ranges or ensuring that a 
> sequence of ranges forms a continuous block.
>
> *Alternatives*:
>
>   * Users could manually compare the |end|?and |start|?of ranges to
>     check contiguity, but this method offers a more explicit and
>     efficient way to perform the check.
>
> ------------------------------------------------------------------------
>
>
>       |Optional<Range<T>> asBounded()|
>
> *Description*:
> Returns the bounded version of the current range, if one exists. If 
> the range is already bounded, it returns the range unchanged. If the 
> range is unbounded, the result is an empty |Optional|. Could be used 
> as a monade for handling errors if range that is expected to be 
> bounded, but unbounded one has been recieved.
>
> *Alternatives:*
>
>   * API could explicitly expose BoundedRange marker (or not marker)
>     interface to verify range that is recieved is bounded at compile
>     time. Interface could provide some adapter methods for converting
>     unknown-boundness ranges to bounded, and have specific behaviour
>     for error cases.
>
>
>       |Range<T>[] splitAt(T point)|
>
> *Description*: Splits the current range into two sub-ranges at the 
> specified point. If the point lies outside the range, it returns an 
> array of length 1 with initial range. If rang |contains()|?point, than 
> array of length 2 is returned, whith two ranges splitted accross given 
> point.
>
>
>       |List<Range<T>> splitInto(int n)|
>
> *Description*:
> Splits the current range into |n|?equal sub-ranges. If the range 
> cannot be evenly divided, the last range may be slightly larger to 
> accommodate the remaining span. Throws 
> |UnsupportedOperationException|?if range is at least half-unbounded.
>
>
>       |Stream<T> pointsFromStartToEnd(??? step)|
>
> *Description*: Returns a list of points that are evenly spaced from 
> the start to the end of the range, using the specified step size. 
> Throws |UnsupportedOperationException|?if range is 
> |isBoundedAtStart()|?returns false.
>
> *Note:*?while this method could have various use cases, It is not 
> clear how step could be provided. One of the options is to pass 
> |Function<T, T>|?that is invoked on each value until value is |> 
> end(|) instrad of constant step.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/d4745150/attachment-0001.htm>

From rotanolexandr842 at gmail.com  Mon Sep 23 19:02:57 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Mon, 23 Sep 2024 22:02:57 +0300
Subject: Range API
In-Reply-To: <9f7972fa-1e50-4c5d-b8cb-b9af5b29e20f@oracle.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <9f7972fa-1e50-4c5d-b8cb-b9af5b29e20f@oracle.com>
Message-ID: <CAL5bRt_f3+h_Qfsu_3xDmMCu4om3XBfAcWpF+0=2TGehAo3oAA@mail.gmail.com>

Hello, Brian

Another consideration I'd like to put on the table is: can it be a value
> type?  Because an immutable range


This was in my thoughts. I would even say it must be a value type. However,
I considered not bothering the Valhalla team unless this API was at least a
candidate.

As has been pointed out already, one would prefer to use a Comparator as a
> witness to ordering rather than the much weaker Comparable.



> I think the algebraic operations as you've proposed them (union,
> intersection, etc) are a bit of a mess, union especially.


As I said, there are a lot of issues with it. Of course I would love to
have such an option in the API, but it has a lot of clashes with range
arithmetic. Maybe I was too fast with the assumption that range
arithmetic is needed in the first place, at least as instance methods. I
will look into possibilities of extracting arithmetic into separate classes
like Math and make Range nore skewed towards data structure with ability to
manipulate it in the procedural fashion. I see that there is still a demand
for things like unions (range sets), and subsequently there will be a
demand for comfortable and standard ways to produce them.

I would want to see Range implement Iterable (yes, I understand this rules
> out some possible types of ranges), as iterating over the elements of a
> range is one of the most likely operations.


I previously did some research on producing streams out of ranges, it has
shown itself pretty well, but API was a bit unintuitive. I will look into
it more carefully though, when more prioritized tasks are completed.

Thanks for your feedback, I appreciate it.

Best regards

On Mon, Sep 23, 2024 at 9:47?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> This is a nice start.  I'd like to add a few comments to help set
> expectations and to guide future explorations here.
>
> Starting with a "main goal" of "putting it in the JDK" is putting the cart
> before the horse.  The main goal should be to solve the problem well
> enough, for a broad enough variety of uses, that it might be _considered as
> a candidate for the JDK_ (possibly with some additional work), but it
> should stand well enough on its own.  (The Joda Time -> java.util.time
> transition is a good example of doing this right.)  Build a good thing
> first, then let's have a conversation about whether it belongs in the JDK.
>
> Another consideration I'd like to put on the table is: can it be a value
> type?  Because an immutable range (and we wouldn't consider anything else)
> is an ideal candidate for being a value.  (This is one of many "is it going
> where the language is going" questions; I'll keep the rest of those to
> myself for now.)
>
> As has been pointed out already, one would prefer to use a Comparator as a
> witness to ordering rather than the much weaker Comparable.
>
> I would want to see Range implement Iterable (yes, I understand this rules
> out some possible types of ranges), as iterating over the elements of a
> range is one of the most likely operations.
>
> I think the algebraic operations as you've proposed them (union,
> intersection, etc) are a bit of a mess, union especially.
>
>
>
>
>
> On 9/22/2024 3:01 PM, Olexandr Rotan wrote:
>
> Hello everyone! I am writing here today to invite everyone to participate
> in the discussion regarding the Range APi proposal I have made into JDK.
> Here is the pull request link: https://github.com/openjdk/jdk/pull/21122,
> and PR text:
>
> This pull request describes the methods of the Range<T> interface. The
> Range<T> interface represents a bounded or unbounded range. (From now on,
> range, span and interval are used interchangeably, but docs only use
> "range")
> Goals:
>
>    -
>
>    *Main goal. Standardization of the Range/Interval API:* The primary
>    objective of this effort is to provide a standardized interface for working
>    with ranges or spans of time (or any ordered types). Many existing
>    libraries offer their own custom implementations of ranges, and they differ
>    in significant ways, making it harder to use and combine across different
>    codebases. Standardization will ensure consistency, interoperability, and a
>    more predictable interface across various contexts.
>    -
>
>    *Versatile range operations:* provide a comprehensive API for
>    manipulating and querying ranges, especially those representing time
>    periods or numerical intervals. The API simplifies common tasks like
>    checking containment, overlaps, or adjacency between ranges.
>    -
>
>    *Support for unbounded ranges:* Unlike many existing libraries, which
>    assume intervals are always bounded, this API aims to fully support
>    unbounded intervals. Users will be able to define ranges with open starts
>    or ends, making it suitable for temporal data that spans indefinitely in
>    one direction, such as future projections or historical data with unknown
>    starting points.
>    -
>
>    *Performance efficiency:* The API aims to provide optimized for
>    performance implementation, that takes advantage of all possible
>    simplifications and short-circuits.
>    -
>
>    *Consistency with existing libraries:* To aid adoption, the API should
>    be familiar to developers who have used popular libraries like NodaTime,
>    Joda-Time, Three-Ten Extra, and Boost Date_Time, but with enhancements for
>    unbounded intervals, negative ranges (?), and optional return types instead
>    of null values.
>
> Non-Goals:
>
>    -
>
>    *Handling complex data structures beyond smple ranges:* This API is
>    not intended to manage or represent complex data structures beyond ranges.
>    For example, ranges that involve intricate internal states, like
>    non-contiguous ranges (?) or ranges with multiple gaps, are out of scope.
>    -
>
>    *Overly simplifying range types:* While ease of use is a goal, its is
>    not an aim to remove support for advanced cases like unbounded or negative
>    ranges, even if this results in slightly more complex implementations. The
>    API should not be skewed towards being purely a simple data structure for
>    bounded ranges.
>    -
>
>    *Application-specific logic:* The API is meant to be domain-agnostic
>    and general-purpose. It is not intended to allow to embed
>    application-specific logic, such as calendar-based date manipulations or
>    domain-specific business rules for interval comparison.
>    -
>
>    *Replacing existing libraries:* The goal is not to replace established
>    libraries like Joda-Time or ThreeTen-Extra, but rather to augment these
>    ideas with support for unbounded ranges and additional arithmetic
>    operations. Although, it is a goal to provide interface that could
>    exisiting libraries could easily retrofit into.
>
> Motivation
>
> The primary motivation behind standardizing the Range API is the *lack of
> an established, universal interface* for handling ranges or spans across
> various domains. Developers are often forced to work with different,
> incompatible range implementations across libraries or to re-implement
> common functionality themselves. This leads to redundant code, increased
> dependencies, and greater chances for errors.
>
> In many software systems?whether in scheduling, auditing, access control,
> or financial services?ranges are used to represent periods of time,
> numerical intervals, or validity spans. Without a standardized API,
> developers must contend with diverse implementations that often differ in
> naming conventions, behavior, and supported features. These variations
> create unnecessary complexity, as developers must:
>
>    1.
>
>    *Introduce additional dependencies*: Many libraries provide similar
>    functionality for ranges, but since they are not interchangeable,
>    developers must often add extra dependencies to cover edge cases or
>    specific use cases that are not available in a single library. This bloats
>    the codebase and creates maintenance overhead.
>    2.
>
>    *Re-implement common logic*: In cases where no single library meets
>    the required needs, developers are forced to write their own range-handling
>    logic. This reinvention of basic operations such as intersection, union, or
>    containment leads to redundancy, increased likelihood of bugs, and
>    inconsistency in how ranges are handled across different parts of the code.
>    3.
>
>    *Fragmentation across domains*: Different libraries often define their
>    own range concepts (e.g., for date-times, numbers, or general comparisons),
>    which are rarely compatible with one another. This lack of compatibility
>    makes integration between systems difficult, requiring custom adapters or
>    conversions.
>
> By defining a standard Range API, the goal is to:
>
>    - *Reduce the dependency footprint:* A common, well-designed API for
>    ranges would eliminate the need to import multiple libraries just to handle
>    different types of ranges, reducing dependencies in projects and enhancing
>    maintainability.
>    - *Simplify code and increase reusability:* With a standardized
>    interface, developers can write range-related code once and reuse it across
>    projects and libraries, confident that the same semantics and operations
>    will apply consistently.
>    - *Minimize developer errors:* By providing a predictable and
>    well-documented interface, the likelihood of misunderstandings or incorrect
>    use of range operations will decrease. Developers can trust that operations
>    like intersections, unions, and comparisons will behave consistently,
>    regardless of the context.
>
> In essence, the lack of standardization in range operations creates
> unnecessary complexity, fragmentation, and redundant effort. A standardized
> Range API would provide clarity, reduce the need for additional
> dependencies, and enable more efficient, reusable, and error-free code
> across different projects and domains.
> Key API points Support of unbounded intervals
>
> API supports both one- and two-sided. Provided sample (draft)
> implementation for ChronoDateTime has 4 separate implementation for each
> type of ranges.
> Alternatives
>
>    - Many Libraries, like Luxon, C++ boost, NodaTime and many others,
>    arguably the most, fo not explicitly support unbounded intervals. This
>    reduces complexity of implementation, but takes away many possible
>    optimization for edge-cases. Alternative they propose is to use Instant.MIN
>    and Instant.MAX or similar to create unbounded-like intervals.
>
> Support for negative intervals,
>
> API supports both positive and negative and positive ranges. This is
> questionable and discussion is encouraged.
> Advantages
>
>    - Allows more flexible usage of API, which would be helpful for use
>    cases like diagrams visualization.
>
> Disadvantages
>
>    - Dramatically increases amount of boilerplate code inside the
>    implementations.
>    - Makes behaviour of potential methods like boolean endsBefore(T t) unintuitive.
>    Does this mean that end() is before that provided parameter, or latter of
>    bounds (i.e. start() for negative range and end() for positive).
>    - Limited usability scope. Most use cases would not benefit from
>    possibility of negative ranges creation, but would have to suffer
>    performance decrease.
>
> In general, either there should be support for negative ranges, or ranges
> might be end-exclusve, but not two at the same time, as having them both
> together dramatically increases complexity.
> Range is not Serializable
>
> Currently ranges are not Serializable. This is due to difficulties
> regarding using non-serializable interfaces, like ChronoDateTIme  in
> sample implementation.
> Alternatives
>
>    - Restrict range type variable to implement Serializable. I see this
>    option as undesiarable bacause of how much it narrows use of interface.
>
> Current interface methods list is minimal
>
> For now, API proposed contains minimal amount of methods that are used in
> range arithmetics. List of methods is supposed to change as discussion
> moves on.
> Generic Range class vs Rnage interface + specific inmplementations
>
> Currently, approach is to define interface and list of implementations.
> Advantages
>
>    - Ability to introduce specialized for type of range methods. For
>    example, Timespan could have Duration toDuration() method, potential
>    IntegerRange could have something like LongRange toLongRange() dur to
>    limitations of comparability between classes. This would be impossible with
>    structural class Range without declaring additional static utility methods.
>    - Enhanced validation of annotaion targets as classes, unlike
>    generics, arent erased.
>
> Disadvantages
>
>    - Increased amount of classes to maintain.
>    - Additional considerations would be required before extending Range
>    interface in case if hierarchy non-sealed to ensure backward compatibility.
>
> API Description NB: Since date ranges is supposed to be one of the most
> popular if not the most popular use case for range, date-time libraries
> were main reference for interface design.
> ------------------------------
> Section: Bounds General notes
>
>    - In *Boost Date_Time* (time_period.begin()), the start and end are
>    always defined, meaning there is no concept of unbounded intervals.
>    Similarly, some libraries like *Chrono* in Rust assume bounded
>    intervals by default. In fact, only a few libraries expose trully unbound
>    ranges. Although, while complexity of implementation is increased by this
>    corner cases, thier performance also vastly increased by cutting amount of
>    operations in each method at least in half (For two-way unbound interval,
>    almost all operations return constnat value).
>
> ------------------------------
> T start()
>
> *Description:*
> Returns the start of the range. If the range is unbounded at the start,
> this method throws an UnsupportedOperationException. This can be
> preemptively checked using isBoundedAtStart().
>
> *Alternatives:*
>
>    - Method could return Optional<T> instead of throwing an exception. I
>    see this two approaches roughly identical in terms of pros/cons score, so
>    suggestions are much appreciated.
>
> ------------------------------
> T end()
>
> *Description*:
> Returns the end of the range. If the range is unbounded at the end, this
> method throws an UnsupportedOperationException. Use isBoundedAtEnd() to
> check if the range is bounded.
>
> *Alternatives:*
>
>    - Simallarly to start(), method could return Optional<T> instead of
>    throwing an exception. I see this two approaches roughly identical in terms
>    of pros/cons score, so suggestions are much appreciated.
>
> ------------------------------
> boolean isBoundedAtStart()
>
> *Description*:
> Returns true if the range is bounded at the start. If unbounded, it
> returns false, meaning calling start() will throw an
> UnsupportedOperationException.
>
> *Alternatives*:
>
>    - *Joda-Time*, *NodaTime*, *Luxon*, and *Moment.js* do not explicitly
>    support unbounded intervals by default but can use null or special
>    values to represent unbounded starts.
>    - *Boost Date_Time* and *Chrono* don?t support unbounded ranges
>    directly, so this method is unnecessary.
>
> ------------------------------
> boolean isBoundedAtEnd()
>
> *Description*:
> Returns true if the range is bounded at the end. A false value means the
> range is unbounded at the end, and calling end() will throw an
> UnsupportedOperationException.
>
> *Alternatives*:
>
>    - Similar to isBoundedAtStart(), most libraries don?t have built-in
>    unbounded intervals, but the concept can be simulated using null,
>    minimal/maximal possible value etc. Pros and cons were described in API
>    notes.
>
> ------------------------------
> Section: boolean operations boolean contains(T instant)
>
> *Description*:
> Returns true if the given instant falls within the start and end bounds
> of the range, otherwise returns false.
>
> *Similar Methods in other libraries*:
>
>    - *NodaTime (Interval.Contains)*
>    - *Joda-Time (Interval.contains)*
>    - *Luxon (Interval.contains)*
>    - *Boost Date_Time (time_period.contains())*
>    - And many others...
>
> *Differences with existing APIs*:
>
>    - *Moment.js* doesn?t provide a direct contains method but the
>    moment-range plugin adds this functionality with range.contains().
>
> *Note*: this method is present in most interval implementations.
> Terefore, I concider as basic and unremovable from the API.
> ------------------------------
> boolean overlaps(Range<? extends T> other)
>
> *Description*:
> Checks if the current range overlaps with another range. Returns true if
> the two ranges overlap, otherwise returns false.
>
> *Similar Methods in other libraries*:
>
>    - *NodaTime (Interval.Overlaps)*
>    - *Joda-Time (Interval.overlaps)*
>    - *Luxon (Interval.overlaps)*
>    - *Boost Date_Time (time_period.intersects())*
>    - And many others...
>
> *Differences with existing APIs*:
>
>    - *Moment.js*: The moment-range plugin provides a similar overlaps() method
>    to check overlap.
>    - *Chrono* relies on custom interval intersection logic.
>
> *Note*: this method is present in most interval implementations.
> Terefore, I concider as basic and unremovable from the API.
> ------------------------------
> General notes on next two methods
>
> Most of the libraries propose API like isBefore(T point) or do not
> provide methods like this at all. Since current implementation throws an
> exception if interval is not bounded, trivial check for isBefore could
> become 4-6 lines long. The question basically comes down to whether the
> Range class should be more data-structure-like or object-like. I would
> argue that at least isBefore(T moment) is required, especially since
> ranges can be negative currently. Existence of boolean isBefore(Range<?
> extends T> other)and similarisAfter` is up to discussion.
> boolean isBefore(Range<? extends T> other)
>
> *Description*:
> Returns true if the current range is strictly before another range (i.e.,
> ends before the other range starts).
>
> *Differences with other libraries*:
>
>    - *NodaTime*: You?d manually compare End of one interval with the Start of
>    another.
>    - *Joda-Time*: Manual comparison with Interval.getEnd() and
>    Interval.getStart().
>    - *Boost Date_Time* and *Chrono* would use custom logic to compare
>    time_period or ranges of time, since they don?t have a direct
>    equivalent of isBefore().
>
> *Alternatives*
>
>    - Most of the libraries propose API like isBefore(T point) or do not
>    provide methods like this at all. Since current implementation throws an
>    exception if interval is not bounded, trivial check for isBefore could
>    become 4-6 lines long. The question basically comes down to whether the
>    Range class should be more data-structure-like or object-like. I would
>    argue that at least isBefore(T moment) is required, especially since
>    ranges can be negative currently
>
> ------------------------------
> boolean isAfter(Range<? extends T> other)
>
> *Description*:
> Returns true if the current range is strictly after another range (i.e.,
> starts after the other range ends).
>
>    - *Similar Methods*:
>       - Similar to isBefore(), manual comparisons are used in *NodaTime*,
>       *Joda-Time*, and *Luxon* an others.
>
> ------------------------------
> boolean isBefore(T point)
>
> *Description:*
> Determines if the span ends before the given point. This is useful when
> you need to check whether a time span occurs entirely before a specific
> point.
>
> *Alternatives*:
>
>    - Method could be removed from APi at all, if Range is desired to be
>    skewed towards being data structure.
>
> ------------------------------
> boolean isAfter(T point)
>
> *Description:*
> Determines if the span starts after the given point. This is useful when
> you need to check whether a time span occurs entirely after a specific
> point.
>
> *Alternatives*:
>
>    - Similarly to boolean isBefore(T point), method could be removed from
>    APi at all, if Range is desired to be skewed towards being data structure.
>
> ------------------------------
> boolean isNegative()
>
> *Description*:
> Returns true if the start of the range is after the end, indicating a
> "negative" range.
>
> *Alternatives:*
>
>    - if concidered too niche, negatie timespans could be removed from
>    model.
>
> *Note:* this one is most questionable for me. Do we really need negative
> ranges? This is most entirely required in numeric ranges and diagrams,
> while introdcues huge complexity overhead for majority that doesnt need
> this feature. Negativity might be confusing for users. Would love to hear
> thoughs on this matter
> ------------------------------
> Section: Range arithmetics Optional<Range<T>> intersection(Range<?
> extends T> other)
>
> *Description*:
> Returns the intersection of the current range with another range. If the
> ranges do not overlap, the result is an empty Optional. If they overlap,
> the intersection is returned.
>
> *Similar Methods*:
>
>    - *NodaTime (Interval.Intersection())*
>    - *Moment.js (via moment-range, range.intersect())*
>    - *Joda-Time (Interval.overlap())*
>    - And many others...
>
> *Differences with existing APIs*:
>
>    - *Boost Date_Time* returns an empty time_period if no overlap exists,
>    instead of an Optional. Some libraries return null (e.g., *NodaTime*).
>    - Other libraries return null if intervals arent overlapping. This is
>    undesrable, so optional returned instead.
>
> *Note*: this method is present in most interval implementations.
> Terefore, I concider as basic and unremovable from the API.
> ------------------------------
> Range<T>[] union(Range<? extends T> other)
>
> *Description*:
> Returns the union of two ranges. If the ranges overlap, the result is a
> single combined range. If they do not overlap, the result is an array of
> two separate ranges.
>
> *Differences with existing APIs*:
>
>    - *NodaTime* and *Joda-Time* support similar logic using custom union
>    handling.
>    - *Boost Date_Time* has no built-in union() function but you can write
>    custom logic to combine or separate intervals.
>
> *Note*: Behaviour of this method is up to change. Currently, it returns
> array for maximal performance, but it can (and most likely should) be
> wrapped in some monadic class. As an alternative, there may be support for
> non-continuous ranges (ones with gaps inside them), then this method should
> return thise kind of range.
> ------------------------------
> Optional<Range<T>> gap(Range<? extends T> other)
>
> *Description*:
> Returns the gap between two ranges, if they do not overlap. If they
> overlap, the result is an empty Optional.
>
> *Differences with existing APIs*:
>
>    - *NodaTime* and *Joda-Time* support custom logic to calculate the gap
>    using isBefore(), isAfter(), and manual calculations of the gap.
>    - Other libraries return null if intervals are overlapping. This is
>    undesrable, so optional returned instead.
>
> ------------------------------
> Section: potential methods boolean isEmpty()
>
> *Description:*
> Determines if the range is "empty,"
>
> Empty range is its own, separate type of range (basically opposite of
> unbounded range). There are many questions regrading this type of range. Is
> it bounded at start or end? If so, what should start() or end() return.
> Them throwing an exception would violate current contract between
> IsBoundedAtX() and 'x()` methods.
>
> *Advantages*
>
>    - Returning empty range instead of Optional might be more user-friendly
>
> *Disadvantages*
>
>    - One more concept in the API model
>    - Corner case in IsBoundedAtX() and 'x()` contract.
>
> Potential Methods for API Enhancement
>
> In this section, we explore methods that could be added to the API,
> comparing them with similar functionality in popular time-related
> libraries. These methods enhance the versatility and clarity of the
> Range<T> implementation, especially in the context of temporal, numeric,
> and other domain-specific ranges. Some of these methods are inspired by
> well-established libraries, while others are novel suggestions.
> ------------------------------
> boolean encloses(Range<? extends T> other)
>
> *Description*:
> Checks whether the current range completely encloses another range, i.e.,
> the other range starts after or at the start of the current range and ends
> before or at the end of the current range.
>
>    -
>
>    *Similar Methods in Other Libraries*:
>    - *NodaTime (Interval.ContainedBy)*
>       - *Joda-Time (Interval.contains)*
>       - *Luxon (Interval.contains)*
>       - *Boost Date_Time (time_period.contains())*
>    -
>
>    *Differences with Existing APIs*:
>    - Some libraries handle encloses() and contains() in the same method.
>       For clarity, this API can separate the two, where contains() is
>       used for checking individual points and encloses() is for
>       range-level comparison.
>
> ------------------------------
> boolean abuts(Range<? extends T> other)
>
> *Description*:
> Returns true if the current range abuts (i.e., touches but does not
> overlap) with another range. This method is useful when determining whether
> two ranges are adjacent but do not overlap.
>
>    -
>
>    *Similar Methods in Other Libraries*:
>    - *NodaTime (Interval.Abuts)*
>    -
>
>    *Alternatives*:
>    - Instead of this method, users could manually compare the end of one
>       range and the start of another, but including abuts() in the API
>       simplifies the logic and reduces error-prone comparisons.
>
> ------------------------------
> Range<T> extendTo(T point)
>
> *Description*:
> Returns a new range that extends the current range to include the given
> point. If the point is already within the range, it returns the current
> range. Otherwise, it extends either the start or end, depending on the
> point's position relative to the range.
>
>    -
>
>    *Similar Methods in Other Libraries*:
>    - *NodaTime* and *Joda-Time* do not have explicit methods for this,
>       but users can manipulate intervals manually.
>       - *Moment.js*: The moment-range plugin offers similar logic via
>       manual adjustments to the range.
>    -
>
>    *Advantages*:
>    - In contrast to manual adjustment, this method automates the process
>       of extending ranges, which can be useful in situations where ranges need to
>       be dynamically modified over time (e.g., expanding time intervals in
>       streaming data).
>
> *Alternatives*:
>
>    - Users could manually adjust the range using start() and end() "withers",
>    but an explicit extendTo() method offers a more intuitive, built-in
>    approach
>
> ------------------------------
> Range<T> shrinkTo(T point)
>
> *Description*:
> Returns a new range that shrinks the current range to exclude the given
> point, if possible. If the point is within the range, the range is modified
> so that it no longer includes the point. This is useful for splitting
> ranges or excluding unwanted time periods or values.
>
>    - *Similar Methods in Other Libraries*:
>    No major time libraries provide a direct equivalent to this
>    functionality, although similar operations can be manually performed by
>    manipulating start and end.
>
> *Alternatives*:
>
>    - Similarly to extendTo, users could manually adjust the range using
>    start() and end() "withers", but an explicit shrinkTo() method offers
>    a more intuitive, built-in approach.
>
> ------------------------------
> Range<T>[] difference(Range<? extends T> other)
>
> *Description*:
> Returns the difference between the current range and another range (XOR
> operations). If the ranges overlap, the result is a new range or two ranges
> representing the non-overlapping portions. If the ranges do not overlap,
> the result is the current range.
>
> *Adavntages*:
>
>    - This method simplifies computing the difference between two ranges,
>    reducing the need for manual boundary comparisons.
>    - Completes set of methods required for ranges arithmetics
>
> *Disdavntages*:
>
>    - THis method is inverse of union(Range<? extends T> other), so it has
>    same design problems as union.
>
> ------------------------------
> Range<T> clamp(Range<? extends T> bounds)
>
> *Description*:
> Clamps the current range to fit within the specified bounds. If the
> current range extends outside of the bounds, it is shortened to fit within
> the bounds. If the range already fits within the bounds, it is returned
> unchanged.
>
> *Advantages*:
>
>    - This method streamlines the process of adjusting a range to a set of
>    bounds, which is especially useful in time-based operations where ranges
>    must be constrained within specific periods (e.g., scheduling).
>
> ------------------------------
> boolean isContiguousWith(Range<? extends T> other)
>
> *Description*:
> Determines if the current range is contiguous with another range, meaning
> that the two ranges touch or overlap without leaving any gaps. This is
> particularly useful when combining ranges or ensuring that a sequence of
> ranges forms a continuous block.
>
> *Alternatives*:
>
>    - Users could manually compare the end and start of ranges to check
>    contiguity, but this method offers a more explicit and efficient way to
>    perform the check.
>
> ------------------------------
> Optional<Range<T>> asBounded()
>
> *Description*:
> Returns the bounded version of the current range, if one exists. If the
> range is already bounded, it returns the range unchanged. If the range is
> unbounded, the result is an empty Optional. Could be used as a monade for
> handling errors if range that is expected to be bounded, but unbounded one
> has been recieved.
>
> *Alternatives:*
>
>    - API could explicitly expose BoundedRange marker (or not marker)
>    interface to verify range that is recieved is bounded at compile time.
>    Interface could provide some adapter methods for converting
>    unknown-boundness ranges to bounded, and have specific behaviour for error
>    cases.
>
> Range<T>[] splitAt(T point)
>
> *Description*: Splits the current range into two sub-ranges at the
> specified point. If the point lies outside the range, it returns an array
> of length 1 with initial range. If rang contains() point, than array of
> length 2 is returned, whith two ranges splitted accross given point.
> List<Range<T>> splitInto(int n)
>
> *Description*:
> Splits the current range into n equal sub-ranges. If the range cannot be
> evenly divided, the last range may be slightly larger to accommodate the
> remaining span. Throws UnsupportedOperationException if range is at least
> half-unbounded.
> Stream<T> pointsFromStartToEnd(??? step)
>
> *Description*: Returns a list of points that are evenly spaced from the
> start to the end of the range, using the specified step size. Throws
> UnsupportedOperationException if range is isBoundedAtStart() returns
> false.
>
> *Note:* while this method could have various use cases, It is not clear
> how step could be provided. One of the options is to pass Function<T, T> that
> is invoked on each value until value is > end() instrad of constant step.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/b4fc2729/attachment-0001.htm>

From iklam at openjdk.org  Mon Sep 23 19:03:53 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 23 Sep 2024 19:03:53 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v4]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <ejXxMifsrCLa-Rk4PYuoApEXChrR_hgpM9H0Nhxsey8=.4d9475ae-eea2-4d13-9bf7-8444589465c3@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - @liach and @cl4es comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @dholmes-ora review comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Do not use system property to limit usage to only CDS static dumps
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/76ef3b33..1c98bfab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=02-03

  Stats: 10 lines in 4 files changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From iklam at openjdk.org  Mon Sep 23 19:03:53 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 23 Sep 2024 19:03:53 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v3]
In-Reply-To: <z-PoWf3mYZAaP5W9MVd78Zec64VaUpx3kgT46-x9Krc=.c9f5e2d4-e82e-499f-8649-ae370fcb6de1@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
 <z-PoWf3mYZAaP5W9MVd78Zec64VaUpx3kgT46-x9Krc=.c9f5e2d4-e82e-499f-8649-ae370fcb6de1@github.com>
Message-ID: <nMYTsoq6RXUFoUiINxZnPkTa4smmnTISc2zxXr-a4KM=.367ef0ed-1b3e-43d1-925c-571aa696ea73@github.com>

On Wed, 18 Sep 2024 12:15:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> How does archiving and resolution of the linked `MethodType` instances work? In particular how does archiving fill up the `MethodType::internTable` to ensure `MethodType` uniqueness?

The details are in the next PR (https://github.com/openjdk/jdk/pull/21143) which is still in draft state. 

At the end of AOT cache assembly phase, the JVM (in `MetaspaceShared::preload_and_dump_impl(()`) upcalls `MethodType::createArchivedObjects()` to copy all MethodTypes into a side table (`MethodType::AOTHolder::archivedMethodTypes`).

During the production run, we first look up from the side table, before checking/interning in the main table.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21049#issuecomment-2369125142

From iklam at openjdk.org  Mon Sep 23 19:03:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 23 Sep 2024 19:03:54 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v3]
In-Reply-To: <c35ig7Etq0YOUxeTlbBu6w-rUHSK3rCavYuP4UzgKl8=.20881d2e-446a-4fe1-8eb3-2fd5c37facee@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <SJAabGC_IcoS0-_UEhl0XpaphrCOZ5y611lkZy3dhTI=.0ed7740c-7193-42e2-9f57-3a2063f61516@github.com>
 <c35ig7Etq0YOUxeTlbBu6w-rUHSK3rCavYuP4UzgKl8=.20881d2e-446a-4fe1-8eb3-2fd5c37facee@github.com>
Message-ID: <BrxMutruZESZaRQBmdgWUfQhiNj9Dlhop2E4Jwxufq0=.94b823a8-dda6-43ee-b5ef-0ab11780fb63@github.com>

On Wed, 18 Sep 2024 05:18:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam 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:
>> 
>>  - @dholmes-ora review comments
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Do not use system property to limit usage to only CDS static dumps
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle
>
> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 148:
> 
>> 146:         public LambdaForm get() {
>> 147:             if (cache instanceof LambdaForm) {
>> 148:                 return (LambdaForm)cache;
> 
> Suggestion:
> 
>             if (cache instanceof LambdaForm lf) {
>                 return lf;

Fixed. Thanks for the suggestion.

> src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 119:
> 
>> 117:             return null;
>> 118:         } else if (entry instanceof MethodHandle) {
>> 119:             return (MethodHandle) entry;
> 
> Suggestion:
> 
>         } else if (entry instanceof MethodHandle mh) {
>             return mh;

Fixed.

> src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 145:
> 
>> 143:             return null;
>> 144:         } else if (entry instanceof LambdaForm) {
>> 145:             return (LambdaForm) entry;
> 
> Suggestion:
> 
>         } else if (entry instanceof LambdaForm lf) {
>             return lf;

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1771936114
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1771936246
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1771936365

From dev at anthonyv.be  Mon Sep 23 19:04:26 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Mon, 23 Sep 2024 19:04:26 +0000
Subject: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB577469B9A299BC7EC6D62779FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
 <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>
 <MW4PR10MB57741DBB8EC8562AD2224B1EFF632@MW4PR10MB5774.namprd10.prod.outlook.com>
 <46bc86380b39b14b20d3d1e589015594b15c1189@anthonyv.be>
 <MW4PR10MB577469B9A299BC7EC6D62779FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <44a9c1cfd7586a141bc2804b43b89c9bc0fc7e73@anthonyv.be>

Hi Viktor

Thanks for bearing with me.

> [...] are you suggesting that we add a section in the Gatherer (and Collector) in the form of "Implementor Notes" that are a bit more high-level than the specification?

Yes, exactly, explicitly mentioning reusability (I actually read through the Javadoc at the time, but didn't connect the dots) and providing guidance/recommending alternatives for use cases where one might be tempted to write a non-reusable Gatherer (I think these use cases can be summarized as: combining a Stream with another Stream, where both Streams might be infinite).

Kind regards, Anthony

September 23, 2024 at 5:19 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> Hi Anthony,
> 
> >The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.
> 
> Even if this is well-intentioned, my experience tells me that this feedback will not materialize, and trying to provoke conformance at runtime will have a noticeable performance impact not encumbering other intermediate operations, especially for processing the bulk majority of streams (which tend to be less than 10 elements in size).
> 
> >This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".
> 
> Adding clarifications to the Javadoc may be the most balanced path forward, in doing so we're talking updating the documentation for both Gatherer and Collector.
> 
> >Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it??
> 
> No, that would be "moving the goalposts" i.e. making Gatherers specified more loosely. Developers will write the code that they write, but if something isn't behaving as expected, it is important to know which side to debug?the library or the user code.
> 
> >?I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers.?
> 
> The ability for developers to implement interfaces (knowingly or unknowingly)?in non-spec-conforming ways aside, are you suggesting that we add a section in the Gatherer (and Collector) in the form of "Implementor Notes" that are a bit more high-level than the specification?
> 
> Cheers,
> 
> ?
> 
> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle
> 
> ????????????????????????????????????????????????????????????????
> 
> **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:**?Thursday, 19 September 2024 20:57
> **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> ?
> 
> Hi Viktor
> 
> > Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather).
> 
> The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.
> 
> This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".
> 
> > java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?
> 
> For `Stream` the package Javadoc has statements like "No storage. A stream is not a data structure" and "Possibly unbounded.", which is sufficient rationale to me.
> 
> For `Collector`, unless I'm missing something, it does not actually specify that it must be reusable, so it does not have to provide a rationale for it either. Even if I did miss something and reusability is implied from the specification: the question would likely never come up, because a Collector will in practice always be reusable anyway (read: I can't readily think of a sensible non-reusable Collector). This is unlike Gatherer, where some obvious use cases such as `concat` and `zip` exist and people like me wonder why such use cases are, apparently needlessly, prohibited by the Gatherer specification.
> 
> > Think of it more like increasing the odds that users are given spec-conformant Gatherers.
> 
> Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it??I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers. Gunnar wrote a blog post [https://urldefense.com/v3/__https://www.morling.dev/blog/zipping-gatherer/__;!!ACWV5N9M2RV99hQ!KmRJAZ0OMfv5XrDKYFVNTJyVWBah899OR9tdZKUHJB928SXc6VEdT4ni1AHI_lGezKchV9kYO04XUdClsg$ ] about his `zip` Gatherer saying "Java 22 [...] promises to improve the situation here." and none of his readers pointed out that his Gatherer is not compliant either (nor complained that his Gatherer is not reusable).
> 
> Kind regards, Anthony
> 
> September 19, 2024 at 11:30 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > Hi Anthony,
> 
> >
> 
> > Bear with me for a moment,
> 
> >
> 
> > in the same vein as there's nothing which *enforces*?equals(?) or hashCode() to be conformant to their specs, or any interface-implementation for that matter, I don't see how we could make any stronger enforcement of Gatherers.
> 
> >
> 
> > >My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
> 
> >
> 
> > Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather). Ultimately, it all boils down to specification?if an equals(?)-method implementation leads to surprising behavior when used with a collection, one typically needs to first ensure that the equals(?)-method conforms to its expected specification before one can presume that the collection has a bug.
> 
> >
> 
> > For the "just work"?scenario, one can only make claims about things which have been proven. So in this case, what tests have passed for the implementation in question?
> 
> >
> 
> > >Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction.?
> 
> > java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?
> 
> >
> 
> > >?"protecting the users from being given non-reusable Gatherers"
> 
> > Think of it more like increasing the odds that users are given spec-conformant Gatherers.
> 
> >
> 
> > Cheers,
> 
> >
> 
> > ?
> 
> >
> 
> > **Viktor Klang**
> 
> > Software Architect, Java Platform Group
> 
> >
> 
> > Oracle
> 
> >
> 
> > ????????????????????????????????????????????????????????????????
> 
> >
> 
> > **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > **Sent:**?Wednesday, 18 September 2024 18:27
> 
> > **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> 
> > ?
> 
> >
> 
> > Hi Viktor
> 
> >
> 
> > Let me start with a question: is the requirement (a) "a Gatherer SHOULD be reusable", or (b) "a Gatherer MUST be reusable"?
> 
> >
> 
> > As of today the specification says (b), whereas the implementation matches (a).
> 
> >
> 
> > In case of (a), I propose to align the specification to allow for compliant, non-reusable Gatherers.
> 
> >
> 
> > In case of (b), I propose to align the implementation to enforce compliance. Something like:
> 
> >
> 
> > (1) invoke `initializer()` twice, giving `i1` and `i2`. Discard `i1` and invoke `i2` twice, giving `state1` and `state2`.
> 
> >
> 
> > (2) invoke `finisher()` twice, giving `f1` and `f2`. Discard `f1` and invoke `f2` twice, the first time with `state1` and a dummy Downstream, the second time with the actual final state, i.e. `state2` after all elements were integrated, and the actual Downstream.
> 
> >
> 
> > Then backport this change to JDK 23 & 22 and/or do another round of preview in JDK 24.
> 
> >
> 
> > I'm confident that enforcing compliance would result in significant amounts of feedback questioning the requirement.
> 
> >
> 
> > My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
> 
> >
> 
> > Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction. You say:
> 
> >
> 
> > > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
> 
> >
> 
> > so I'd guess the rationale is?"protecting the users from being given non-reusable Gatherers".
> 
> >
> 
> > However, I can't readily think of a situation where this would be essential.
> 
> >
> 
> > If a user creates a Gatherer by invoking a factory method, the factory method can specify whether its result is reusable.
> 
> >
> 
> > And if a user is given a Gatherer as a method argument, and they need the Gatherer to be reusable, they could change the parameter to a `Supplier<Gatherer>` instead.
> 
> >
> 
> > > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
> 
> >
> 
> > >
> 
> >
> 
> > > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
> 
> >
> 
> > We agree, just that I'd provide 2 factory methods, `concat(Stream<T>)` (non-reusable) and `append(List<T>)` (reusable), whereas you'd provide a 2-in-1 `concat(Supplier<Stream<T>>)`.
> 
> >
> 
> > Kind regards, Anthony
> 
> >
> 
> > September 12, 2024 at 11:55 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > >
> 
> >
> 
> > > Hi Anthony
> 
> >
> 
> > >
> 
> >
> 
> > > Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.
> 
> >
> 
> > >
> 
> >
> 
> > > >While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
> 
> >
> 
> > >
> 
> >
> 
> > > To me, this is governed by the following parts of the Gatherer specification https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html?:
> 
> >
> 
> > >
> 
> >
> 
> > > "Each invocation of initializer() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer()?,integrator()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator()?,combiner()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner()?, and finisher()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher()??must return a semantically identical result."
> 
> >
> 
> > >
> 
> >
> 
> > > and
> 
> >
> 
> > >
> 
> >
> 
> > > "Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstreamGatherer.Downstreamhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html?PREVIEWhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream??for longer than the invocation duration of the method which they are passed to."
> 
> >
> 
> > >
> 
> >
> 
> > > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
> 
> >
> 
> > >
> 
> >
> 
> > > For Stream, the assumption is that they are NOT reusable at all.
> 
> >
> 
> > > For Gatherer, I think the only reasonable assumption is that they are reusable.
> 
> >
> 
> > >
> 
> >
> 
> > > >In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?
> 
> >
> 
> > >
> 
> >
> 
> > > Not necessarily, if the factory method **consumes**?the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.
> 
> >
> 
> > >
> 
> >
> 
> > > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
> 
> >
> 
> > >
> 
> >
> 
> > > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
> 
> >
> 
> > >
> 
> >
> 
> > > >As another example, take Gunnar Morling's zip Gatherers:?
> 
> >
> 
> > >
> 
> >
> 
> > > I don't see how Gatherers like this could be made reusable, or why that would even be desirable.
> 
> >
> 
> > >
> 
> >
> 
> > > Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().
> 
> >
> 
> > >
> 
> >
> 
> > > >My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
> 
> >
> 
> > >
> 
> >
> 
> > > My apologies, I misunderstood. To me, the operation you describe is called `inject`.
> 
> >
> 
> > > Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.
> 
> >
> 
> > >
> 
> >
> 
> > > Thanks again for the great questions and conversation, it's valuable!
> 
> >
> 
> > > Cheers,
> 
> >
> 
> > >
> 
> >
> 
> > > ?
> 
> >
> 
> > >
> 
> >
> 
> > > **Viktor Klang**
> 
> >
> 
> > > Software Architect, Java Platform Group
> 
> >
> 
> > >
> 
> >
> 
> > > Oracle
> 
> >
> 
> > >
> 
> >
>

From kvn at openjdk.org  Mon Sep 23 19:16:39 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 23 Sep 2024 19:16:39 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v12]
In-Reply-To: <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
Message-ID: <OF1gT2DxAKhZuQnes0JNCPtIU5MINXWkFfIU7aXrp7w=.645d623b-781c-4680-96e0-7d6269013d13@github.com>

On Thu, 19 Sep 2024 21:15:11 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix is_intrinsic_supported to work properly

Looks good. I have only one nitpick. I will start testing.

src/hotspot/share/c1/c1_Compiler.cpp line 170:

> 168:   case vmIntrinsics::_dcos:
> 169:   case vmIntrinsics::_dtan:
> 170:   #if defined(X86)

Use `#ifdef AMD64` for x64 only

-------------

PR Review: https://git.openjdk.org/jdk/pull/20657#pullrequestreview-2323102058
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1771949759

From liach at openjdk.org  Mon Sep 23 19:18:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 19:18:37 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v4]
In-Reply-To: <ejXxMifsrCLa-Rk4PYuoApEXChrR_hgpM9H0Nhxsey8=.4d9475ae-eea2-4d13-9bf7-8444589465c3@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <ejXxMifsrCLa-Rk4PYuoApEXChrR_hgpM9H0Nhxsey8=.4d9475ae-eea2-4d13-9bf7-8444589465c3@github.com>
Message-ID: <tbJ5qgkuaqI2fJvbR08NqS4rzCkojjIlPC-34sTO9Qc=.f71c3e4e-915a-41e9-9612-70f67ee993be@github.com>

On Mon, 23 Sep 2024 19:03:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2323114661

From duke at openjdk.org  Mon Sep 23 19:24:51 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 23 Sep 2024 19:24:51 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  change ifdef from x86 to AMD64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/5da2754a..4dc2e36a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From duke at openjdk.org  Mon Sep 23 19:24:51 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 23 Sep 2024 19:24:51 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v12]
In-Reply-To: <OF1gT2DxAKhZuQnes0JNCPtIU5MINXWkFfIU7aXrp7w=.645d623b-781c-4680-96e0-7d6269013d13@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <ndp-aZ-RNCyBK-kfc5mvHBZ8uq4OSOEv2E0hcNgOeI8=.9a8afb62-2786-47f5-8210-2cfa4e38e099@github.com>
 <OF1gT2DxAKhZuQnes0JNCPtIU5MINXWkFfIU7aXrp7w=.645d623b-781c-4680-96e0-7d6269013d13@github.com>
Message-ID: <D508LI-PjyOXkaHHMbGbjpPckRl6wq0lhefmbW00J2Y=.90f3cd48-b7c2-4461-bc62-b59b08db8f55@github.com>

On Mon, 23 Sep 2024 19:14:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks good. I have only one nitpick. I will start testing.

Thank you Vladimir!

> src/hotspot/share/c1/c1_Compiler.cpp line 170:
> 
>> 168:   case vmIntrinsics::_dcos:
>> 169:   case vmIntrinsics::_dtan:
>> 170:   #if defined(X86)
> 
> Use `#ifdef AMD64` for x64 only

Thanks Vladimir! Please see the code updated with `#ifdef AMD64`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2369168165
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1771961469

From rafael.wth at gmail.com  Mon Sep 23 19:35:45 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Mon, 23 Sep 2024 21:35:45 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
Message-ID: <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>

So I tracked down the discrepancy to a changing default for URLClassLoader
compared to JarFile. URLClassLoader resolves resources to the "versions"
folder for Java 9 and later, even without code changes. This is not the
case for JarFile where the relevant version needs to be passed to a new
constructor that is introduced in Java 9, requiring code changes.

This creates a new problem to me however: I can look up a META-INF/versions
resource in a multi-release jar, when using a class loader, no matter the
JVM version. I can however not look up the original "non-META-INF"
resource. I have been browsing the source code, and this seems to be
impossible, is that right? This again brings me back to my original
suggestion. Should there be a method in ClassLoader (and JarFile) that
allows locating a resource for a given version? In code instrumentation
tools, mostly for build, but also for agents, it can be rather essential to
query class file stores for specific versions.

I learned in the process that multi-release jars can contain anything, not
only classes. Therefore, I wonder if adding a method like the following
would be reasonable?

public InputStream getResourceAsStream(String name, Runtime.Version
version) {
  return getResourceAsStream(name);
}

This would allow MR-aware class loaders an option to expose resources
independently of the current JVM version.

Best regards, Rafael

Am So., 22. Sept. 2024 um 20:45 Uhr schrieb Alan Bateman <
alan.bateman at oracle.com>:

> On 22/09/2024 17:45, Rafael Winterhalter wrote:
> > That is only true for Class::getResource which resolves resources
> > relative to the loaded class's class file location. Java agents
> > typically use ClassLoader::getResource(AsStream) as the loaded class
> > is not available in the general case of transforming, and not
> > retransforming, a class. For example, when instrumenting a newly
> > loaded class A in a ClassFileTransformer, it might not be the case
> > that its superclass B is loaded. If class B exists in two versions as
> > part of a multi-release jar file, currently, you need to query the
> > class loader of A as the JVM would do. When loading a class,
> > ClassLoader::findClass respects the multi-release characteristic. But
> > for ClassLoader::getResource, this is not the case. This is why I want
> > to suggest a new method where this is possible, as the intend to
> > resolve a class file is explicit. Currently, you need to iterate as
> > the ClassLoader does not expose any relevant information.
>
> If a URLClassLoader is created with a URL to a JAR file then it should
> open it as a MR-JAR and getResource should find the .class resources in
> the versioned section. Are you saying that this doesn't work? If it
> doesn't work then I think it would be useful to show the
> getResource(name) output. If the resource is versioned then you end with
> "!/META-INF/versions/$N/$R". But maybe this is a different type of
> ClassLoader?
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/2a755a5f/attachment.htm>

From rotanolexandr842 at gmail.com  Mon Sep 23 21:02:11 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Tue, 24 Sep 2024 00:02:11 +0300
Subject: Range API
In-Reply-To: <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
Message-ID: <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>

>
> But do those two use cases really need an abstraction? Is there really
> value in a Range interface?
> Given the two classes above, which are IMO candidates for the JDK, they
> work fine as isolated value types without a generalized abstraction.


I see this a bit differently. In the examples you provided, there are
basically no methods that would somehow indicate that Interval is something
more than generic Range<Instant> besides toDuration(), and same goes for
LocalDateRange. Therefore, I see generic ranges not as "abstracting"
ranges, but rather adapting them for the general case. Range<Instant> and
Interval are roughly identical, with differences easily coverable by few
static methods.

Similarly, I'm not sure what a Range value type would accomplish. Don't get
> me wrong - if fully integrated into the language, with literals and looping
> syntax there might be a case, but we are a long way from that.


Well, every feature started somewhere. There is clearly a demand for range
support, both numeric, chronological, and potentially many others. Amber is
considering integrating ranges as patterns, so anyway internal
representation will be needed.

Sorry to be a bit down given the massive effort made here, but the harsh
> truth is that I've yet to see a "Range" API that I like, and I especially
> find mixing bounded/unbounded and inclusive/exclusive gets complicated and
> unpleasant very fast.


Your opinion is valuable too. I am not pushing on integrating this changes,
PR mostly serves research purpose, and final form could (and most likely
will) differ a lot from the current state of API.

Ranges are indeed not easy to model, they always could use some
syntax-level dsl. If the demand shows to be high enough, this may also be
the subject of discussion. Nevertheless, ranges in general are really
popular. Chronological ranges are one of the most common business object
attributes, numeric ranges could be useful for research and visualization
etc. For now, I will continue on evolving the API, to see if it is possible
to arrive at the point where the API is smooth enough to become a candidate.

PS: Regarding chronological ranges specifically, this was my motivation in
the first place (
https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125271.html)..I
was initially a fan of nominal date and time ranges, but when I started
modeling the API, I discovered that, surprisingly, there is little to none
tdatetime-specific operations that could be made on ranges. Therefore, I
came to the conclusion that ranges generalize too well to miss on this.
Some people here argue it is too strict to oblige range elements to be
comparable, let alone chronological types.

On Mon, Sep 23, 2024 at 11:24?PM Stephen Colebourne <scolebourne at joda.org>
wrote:

> I've always found the generic concept of a "range" tricky to express
> in a sensible API. When authoring Joda-Time and java.time I avoided it
> as much as possible.
>
> ThreeTen-Extra has two classes - Interval and LocalDateRange - which
> cover the two main use cases.
>
> https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/package-summary.html
>
> But do those two use cases really need an abstraction? Is there really
> value in a Range interface?
> Given the two classes above, which are IMO candidates for the JDK,
> they work fine as isolated value types without a generalized
> abstraction.
>
> Similarly, I'm not sure what a Range value type would accomplish.
> Don't get me wrong - if fully integrated into the language, with
> literals and looping syntax there might be a case, but we are a long
> way from that. (ie. some language designs are built around ranges as a
> first class concept, but Java isn't, and I have doubts that it would
> be a good fit to try and pivot that way now.) In particular, I
> struggle with a generified Range type - it just "feels wrong" to me.
>
> Sorry to be a bit down given the massive effort made here, but the
> harsh truth is that I've yet to see a "Range" API that I like, and I
> especially find mixing bounded/unbounded and inclusive/exclusive gets
> complicated and unpleasant very fast. And that is before you consider
> discrete versus continuous.
> Stephen
>
>
> On Sun, 22 Sept 2024 at 20:02, Olexandr Rotan
> <rotanolexandr842 at gmail.com> wrote:
> >
> > Hello everyone! I am writing here today to invite everyone to
> participate in the discussion regarding the Range APi proposal I have made
> into JDK. Here is the pull request link:
> https://github.com/openjdk/jdk/pull/21122, and PR text:
> >
> > This pull request describes the methods of the Range<T> interface. The
> Range<T> interface represents a bounded or unbounded range. (From now on,
> range, span and interval are used interchangeably, but docs only use
> "range")
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/9764206c/attachment-0001.htm>

From mcimadamore at openjdk.org  Mon Sep 23 21:06:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 21:06:12 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix javadoc test failure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/eb2cc990..0e0944ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=03-04

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From mcimadamore at openjdk.org  Mon Sep 23 21:06:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Sep 2024 21:06:12 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
Message-ID: <5sDVx0XJrcqybukBtqIWjVtRowbOK1ssyRttAJ9vxaI=.38a0c9ff-cef2-4442-a1ec-364753271ef4@github.com>

On Mon, 23 Sep 2024 21:03:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc test failure

test/langtools/jdk/javadoc/doclet/testRestricted/TestRestricted.java line 45:

> 43:     public static void main(String... args) throws Exception {
> 44:         var tester = new TestRestricted();
> 45:         tester.setAutomaticCheckLinks(false);

@hns I had to disable this check because otherwise the test framework will attempt (and fail) to resolve `../java.base/java/lang/doc-files/RestrictedMethods.html`. Is there a better way to do this w/o disabling the link checks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1772072696

From liach at openjdk.org  Mon Sep 23 21:42:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 21:42:11 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v7]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <AMxoGDMN6-WeZxl4C0YAoghVXdljlPU1txA5o3YYnK4=.429a82d9-6490-44e4-aec9-c239b8d6bc58@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Move raw opcodes to impl only
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - omission in tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Rename constants at new locations, link to related factories, cp tag constant names
 - Fix compile errors
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e97f0fe1...8b03ad17

-------------

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=06
  Stats: 2445 lines in 37 files changed: 537 ins; 908 del; 1000 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

PR: https://git.openjdk.org/jdk/pull/20773

From liach at openjdk.org  Mon Sep 23 21:52:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 21:52:37 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v7]
In-Reply-To: <AMxoGDMN6-WeZxl4C0YAoghVXdljlPU1txA5o3YYnK4=.429a82d9-6490-44e4-aec9-c239b8d6bc58@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <AMxoGDMN6-WeZxl4C0YAoghVXdljlPU1txA5o3YYnK4=.429a82d9-6490-44e4-aec9-c239b8d6bc58@github.com>
Message-ID: <JT3FjHg_hNO_R9WH1UE6aeuiUB9BemtiXdBj0k5zu1o=.c609a0a1-8031-42e9-99ce-5095cf49f349@github.com>

On Mon, 23 Sep 2024 21:42:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Move raw opcodes to impl only
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - omission in tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Rename constants at new locations, link to related factories, cp tag constant names
>  - Fix compile errors
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e97f0fe1...8b03ad17

@asotona Updated and removed the opcode raw values; they are exposed just through `Opcode::bytecode` and the raw values are moved to `RawBytecodeHelper`. If users demand these raw values, we can add back later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20773#issuecomment-2369553635

From duke at openjdk.org  Mon Sep 23 22:07:40 2024
From: duke at openjdk.org (duke)
Date: Mon, 23 Sep 2024 22:07:40 GMT
Subject: Withdrawn: 8303884: jlink --add-options plugin does not allow GNU
 style options to be provided
In-Reply-To: <ia9RrTWpgdTHdk7cKpEtHfHD3VtLczKboBcutdxAAG4=.04cc7b80-3779-4c10-9c9a-50e9ddc76b2a@github.com>
References: <ia9RrTWpgdTHdk7cKpEtHfHD3VtLczKboBcutdxAAG4=.04cc7b80-3779-4c10-9c9a-50e9ddc76b2a@github.com>
Message-ID: <Jj8pqZnYtzKzKOBwEimUqbrHBykpCV--UUKopcciKzM=.2d2e55d0-d017-4493-b1e0-721395968d6d@github.com>

On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We cannot pass GNU style options like `--enable-preview` to `jlink --add-option`. It is hard to use for complex application.
> 
> We have workaround for this issue (see JBS), but I think it is better to fix on JDK side.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19987

From liach at openjdk.org  Mon Sep 23 22:23:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Sep 2024 22:23:47 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v5]
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <dWPf46MgKHrJSG-8jg0d83AX-sWkIK2vMt-_Ox9mnR4=.79950cf6-f67d-4716-a9ec-5b79249f3727@github.com>

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Fresh creation bench
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Fix build
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Buggy 2nd attempt - crashes hotspot
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - More conflicts
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - ... and 8 more: https://git.openjdk.org/jdk/compare/e97f0fe1...7f79042a

-------------

Changes: https://git.openjdk.org/jdk/pull/20667/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20667&range=04
  Stats: 689 lines in 7 files changed: 594 ins; 42 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/20667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20667/head:pull/20667

PR: https://git.openjdk.org/jdk/pull/20667

From swen at openjdk.org  Mon Sep 23 23:23:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 23 Sep 2024 23:23:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v19]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <KC5Z--UoI5bQj9T3KWD-Nj3CvHqIlyHKpYpkVp_6wCE=.305930b1-4591-4fbc-a14d-7e93b53993f1@github.com>

> 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 incrementally with one additional commit since the last revision:

  fix build error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/399c8ef5..ae054771

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=17-18

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From asemenyuk at openjdk.org  Tue Sep 24 00:16:47 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Sep 2024 00:16:47 GMT
Subject: Integrated: 8338918: Remove non translated file name from WinResources
 resource bundle
In-Reply-To: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
References: <yCgT6S_PQttf47nMTyEc0zE5wThH6sgz18vHDZNE6_c=.1019b2d2-266b-469d-bd8d-a7851b10d95f@github.com>
Message-ID: <n6aavDliThaR0n893dTx3qB8xM7mUsgg2RGewdu79vE=.72e6c589-4272-425c-9a2b-7ce7287b3e4d@github.com>

On Thu, 19 Sep 2024 23:37:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move `resource.wxl-file-name` property from `WinResources.properties` files to the new `WinResourcesNoL10N.properties` files. The later are supposed to be excluded from automatic translations.

This pull request has now been integrated.

Changeset: cd796e0a
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd796e0aef321d46c96f79dc5446d095b8a30e60
Stats:     63 lines in 9 files changed: 41 ins; 13 del; 9 mod

8338918: Remove non translated file name from WinResources resource bundle

Reviewed-by: jlu, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/21100

From duke at openjdk.org  Tue Sep 24 00:28:44 2024
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 24 Sep 2024 00:28:44 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account the
 size of a CEN header
Message-ID: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>

8340553: ZipEntry field validation does not take into account the size of a CEN header

-------------

Commit messages:
 - 8340553: ZipEntry field validation does not take into account the size of a CEN header
 - 8340553: ZipEntry field validation does not take into account the size of a CEN header

Changes: https://git.openjdk.org/jdk/pull/21147/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21147&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340553
  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21147/head:pull/21147

PR: https://git.openjdk.org/jdk/pull/21147

From duke at openjdk.org  Tue Sep 24 00:38:47 2024
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 24 Sep 2024 00:38:47 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
References: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
Message-ID: <4fKziOJnUjqyjal9ErOxDaCiPQ0XgshCUqUnzIxcVCk=.9412602b-07b0-4a9a-8fa7-3f8325b3dcfd@github.com>

> 8340553: ZipEntry field validation does not take into account the size of a CEN header

Lei Zhu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8340553: ZipEntry field validation does not take into account the size of a CEN header

-------------

Changes: https://git.openjdk.org/jdk/pull/21147/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21147&range=01
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21147/head:pull/21147

PR: https://git.openjdk.org/jdk/pull/21147

From swen at openjdk.org  Tue Sep 24 00:49:49 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 00:49:49 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod
Message-ID: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>

A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 286

-------------

Commit messages:
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - optimize processMethod

Changes: https://git.openjdk.org/jdk/pull/21137/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340708
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21137/head:pull/21137

PR: https://git.openjdk.org/jdk/pull/21137

From liach at openjdk.org  Tue Sep 24 00:49:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 00:49:49 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod
In-Reply-To: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
Message-ID: <CZa7HulErT6STuauL9aq69ipsyUWUXCJE3_hBVYriRo=.fc4ff73a-a67a-4631-8992-26852e72b3bf@github.com>

On Mon, 23 Sep 2024 13:53:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 286

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 432:

> 430:                     nextFrame.dirty = false;
> 431:                 } else if (thisOffset < bcs.bci()) {
> 432:                     throw new ClassFormatError(String.format("Bad stack map offset %d", thisOffset));

@asotona Is this CFE an outdated implementation behavior from an older implementation? If yes, we can just use `generatorError("Bad stack map offset");` instead.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 444:

> 442: 
> 443:     private static ClassFormatError classFormatError(int thisOffset) {
> 444:         throw new ClassFormatError(String.format("Bad stack map offset %d", thisOffset));

Suggestion:

        return new ClassFormatError(String.format("Bad stack map offset %d", thisOffset));

Prefer to return instead of throw in such convenience methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21137#discussion_r1771672919
PR Review Comment: https://git.openjdk.org/jdk/pull/21137#discussion_r1771673590

From asotona at openjdk.org  Tue Sep 24 00:49:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 24 Sep 2024 00:49:49 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod
In-Reply-To: <CZa7HulErT6STuauL9aq69ipsyUWUXCJE3_hBVYriRo=.fc4ff73a-a67a-4631-8992-26852e72b3bf@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
 <CZa7HulErT6STuauL9aq69ipsyUWUXCJE3_hBVYriRo=.fc4ff73a-a67a-4631-8992-26852e72b3bf@github.com>
Message-ID: <yftbEnuF_G9tjiD0Dc-TM_dlq1T7zXKtAcIUJja8HZI=.69bbec27-0630-4647-a8a4-80898ba119d7@github.com>

On Mon, 23 Sep 2024 15:27:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 286
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 432:
> 
>> 430:                     nextFrame.dirty = false;
>> 431:                 } else if (thisOffset < bcs.bci()) {
>> 432:                     throw new ClassFormatError(String.format("Bad stack map offset %d", thisOffset));
> 
> @asotona Is this CFE an outdated implementation behavior from an older implementation? If yes, we can just use `generatorError("Bad stack map offset");` instead.

Yes, good catch. I thought we already get rid of these :)

> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 444:
> 
>> 442: 
>> 443:     private static ClassFormatError classFormatError(int thisOffset) {
>> 444:         throw new ClassFormatError(String.format("Bad stack map offset %d", thisOffset));
> 
> Suggestion:
> 
>         return new ClassFormatError(String.format("Bad stack map offset %d", thisOffset));
> 
> Prefer to return instead of throw in such convenience methods.

The same here - we should not throw CFE anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21137#discussion_r1771677571
PR Review Comment: https://git.openjdk.org/jdk/pull/21137#discussion_r1771680222

From kvn at openjdk.org  Tue Sep 24 01:04:38 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 24 Sep 2024 01:04:38 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
Message-ID: <fdGHI439-IJOij1vJ17eN-KxFhpR9CnxdrqXzQtr0p0=.3bfe4ea4-d6ee-4cc0-922b-d087a6ab17ff@github.com>

On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change ifdef from x86 to AMD64

My testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20657#pullrequestreview-2323769774

From swen at openjdk.org  Tue Sep 24 01:15:15 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 01:15:15 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
Message-ID: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>

Do some refactoring so that the code can be inlined by the C1/C2 optimizer.

1. DirectClassBuilder::build codeSize 361 -> 315
2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
4. BufWriterImpl::writeU2 (forceinline)
5. Util::writeAttributes codSize 45 -> 40 (forceinline)
6. Util::writeList codSize 47 -> 42 (forceinline)

-------------

Commit messages:
 - inline writeLong & local constantPool
 - fix write header
 - suggestion from @liach
 - force inline Util::writeAttributes & Util::writeList
 - force inline writeU2
 - force inline invalidIndex
 - optimize for writeExceptionHandlers for C1
 - optimize DirectClassBuilder::build

Changes: https://git.openjdk.org/jdk/pull/21118/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340710
  Stats: 50 lines in 4 files changed: 31 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21118.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21118/head:pull/21118

PR: https://git.openjdk.org/jdk/pull/21118

From swen at openjdk.org  Tue Sep 24 01:15:16 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 01:15:16 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <TsWn3PflGJH4btVIxysUsH27enXGpZALV5oU8xK630c=.1f29376d-66ef-4506-ba44-72cfef71f7be@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
 <TsWn3PflGJH4btVIxysUsH27enXGpZALV5oU8xK630c=.1f29376d-66ef-4506-ba44-72cfef71f7be@github.com>
Message-ID: <83eOm9B6ykgxcQjOPOO6Qt2ZplESoI8tY8y3wsp16RU=.4c1f3d36-c09f-4fa2-acbe-dc6968dac118@github.com>

On Mon, 23 Sep 2024 00:33:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
>> 
>> 1. DirectClassBuilder::build codeSize 361 -> 315
>> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
>> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
>> 4. BufWriterImpl::writeU2 (forceinline)
>> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
>> 6. Util::writeList codSize 47 -> 42 (forceinline)
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 99:
> 
>> 97:     }
>> 98: 
>> 99:     void writeMagic(int minorVersion, int majorVersion) {
> 
> Can we call this `writeHeader` as this writes both the magic and the version?

Now, through the local variable constantPool, codeSize < 325 can be achieved without extracting a separate method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1771513668

From liach at openjdk.org  Tue Sep 24 01:15:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 01:15:16 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <MSQoBVcvbxMANLSGlaGrm7cN8xj5Txt5Uua3h4S4cGk=.77fd0069-a359-4c80-a85d-f054c196fe45@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
 <MSQoBVcvbxMANLSGlaGrm7cN8xj5Txt5Uua3h4S4cGk=.77fd0069-a359-4c80-a85d-f054c196fe45@github.com>
Message-ID: <hRLN_MNdgWtdIPOK1i6BQ_xBOXGo6PJp72cH1NyIRq8=.a329715d-2174-4ece-adae-3a5dad886d92@github.com>

On Sun, 22 Sep 2024 17:04:24 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
>> 
>> 1. DirectClassBuilder::build codeSize 361 -> 315
>> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
>> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
>> 4. BufWriterImpl::writeU2 (forceinline)
>> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
>> 6. Util::writeList codSize 47 -> 42 (forceinline)
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java line 207:
> 
>> 205: 
>> 206:         // Now we can make the head
>> 207:         head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 | minorVersion << 16 | majorVersion);
> 
> `minorVersion` needs to?be?cast to?a?`long`?first, as?otherwise when?the?MSB?is?set after?the?shift, then?it?ll?overwrite the?magic?number with?all?1s.
> 
> Suggestion:
> 
>         head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 | ((long) minorVersion) << 16 | majorVersion);

For clarity, I think using Integer.toUnsignedLong on the shift result is better

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1770632933

From swen at openjdk.org  Tue Sep 24 01:15:16 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 01:15:16 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <hRLN_MNdgWtdIPOK1i6BQ_xBOXGo6PJp72cH1NyIRq8=.a329715d-2174-4ece-adae-3a5dad886d92@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
 <MSQoBVcvbxMANLSGlaGrm7cN8xj5Txt5Uua3h4S4cGk=.77fd0069-a359-4c80-a85d-f054c196fe45@github.com>
 <hRLN_MNdgWtdIPOK1i6BQ_xBOXGo6PJp72cH1NyIRq8=.a329715d-2174-4ece-adae-3a5dad886d92@github.com>
Message-ID: <6Tyvfk6T19jICrP55kZgBqCLfsj_GHnRgP0EFi07UAk=.fa653a9a-db07-4cad-82b7-3146ae4fbf17@github.com>

On Sun, 22 Sep 2024 20:48:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java line 207:
>> 
>>> 205: 
>>> 206:         // Now we can make the head
>>> 207:         head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 | minorVersion << 16 | majorVersion);
>> 
>> `minorVersion` needs to?be?cast to?a?`long`?first, as?otherwise when?the?MSB?is?set after?the?shift, then?it?ll?overwrite the?magic?number with?all?1s.
>> 
>> Suggestion:
>> 
>>         head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 | ((long) minorVersion) << 16 | majorVersion);
>
> For clarity, I think using Integer.toUnsignedLong on the shift result is better

If minorVersion > 0xFFFF, the result of using Integer.toUnsignedLong will be wrong. I guess this is the reason why the previous version build failed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1770667423

From liach at openjdk.org  Tue Sep 24 01:15:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 01:15:16 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
Message-ID: <TsWn3PflGJH4btVIxysUsH27enXGpZALV5oU8xK630c=.1f29376d-66ef-4506-ba44-72cfef71f7be@github.com>

On Sun, 22 Sep 2024 05:30:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
> 
> 1. DirectClassBuilder::build codeSize 361 -> 315
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
> 4. BufWriterImpl::writeU2 (forceinline)
> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
> 6. Util::writeList codSize 47 -> 42 (forceinline)

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 99:

> 97:     }
> 98: 
> 99:     void writeMagic(int minorVersion, int majorVersion) {

Can we use `writeLong(((long) MAGIC_NUMBER) << 32 | minorVersion << 16 | majorVersion);`?

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 99:

> 97:     }
> 98: 
> 99:     void writeMagic(int minorVersion, int majorVersion) {

Can we call this `writeHeader` as this writes both the magic and the version?

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 256:

> 254:         int size = list.size();
> 255:         buf.writeU2(size);
> 256:         for (int i = 0; i < size; i++) {

? Manual loop unrolling is good for startup

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1770556482
PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1770670377
PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1770556848

From duke at openjdk.org  Tue Sep 24 01:15:16 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 24 Sep 2024 01:15:16 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
Message-ID: <MSQoBVcvbxMANLSGlaGrm7cN8xj5Txt5Uua3h4S4cGk=.77fd0069-a359-4c80-a85d-f054c196fe45@github.com>

On Sun, 22 Sep 2024 05:30:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
> 
> 1. DirectClassBuilder::build codeSize 361 -> 315
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
> 4. BufWriterImpl::writeU2 (forceinline)
> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
> 6. Util::writeList codSize 47 -> 42 (forceinline)

src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java line 207:

> 205: 
> 206:         // Now we can make the head
> 207:         head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 | minorVersion << 16 | majorVersion);

`minorVersion` needs to?be?cast to?a?`long`?first, as?otherwise when?the?MSB?is?set after?the?shift, then?it?ll?overwrite the?magic?number with?all?1s.

Suggestion:

        head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 | ((long) minorVersion) << 16 | majorVersion);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1770595427

From liach at openjdk.org  Tue Sep 24 01:15:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 01:15:16 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <6Tyvfk6T19jICrP55kZgBqCLfsj_GHnRgP0EFi07UAk=.fa653a9a-db07-4cad-82b7-3146ae4fbf17@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
 <MSQoBVcvbxMANLSGlaGrm7cN8xj5Txt5Uua3h4S4cGk=.77fd0069-a359-4c80-a85d-f054c196fe45@github.com>
 <hRLN_MNdgWtdIPOK1i6BQ_xBOXGo6PJp72cH1NyIRq8=.a329715d-2174-4ece-adae-3a5dad886d92@github.com>
 <6Tyvfk6T19jICrP55kZgBqCLfsj_GHnRgP0EFi07UAk=.fa653a9a-db07-4cad-82b7-3146ae4fbf17@github.com>
Message-ID: <ODWWDFi8DCXwRo0f_gTKKUxkntoYQ0-XkbL-A5BqgDo=.e47d9617-602a-42af-b286-985949acc591@github.com>

On Mon, 23 Sep 2024 00:20:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> For clarity, I think using Integer.toUnsignedLong on the shift result is better
>
> If minorVersion > 0xFFFF, the result of using Integer.toUnsignedLong will be wrong. I guess this is the reason why the previous version build failed

Should we add a `& 0xFFFF` on `majorVersion` to defend against `majorVersion > 0xFFFF` too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1772318887

From liach at openjdk.org  Tue Sep 24 01:20:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 01:20:38 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod
In-Reply-To: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
Message-ID: <SbeoG07rzwyo7F1QbwNn06FVPQqgv9ARTIKfJQHJKpg=.4fe1d2dc-0107-4d12-a721-634abcf55dfd@github.com>

On Mon, 23 Sep 2024 13:53:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 286

@wenshao Can you change the method to call generatorError? The ClassFormatError was a bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21137#issuecomment-2369912027

From iklam at openjdk.org  Tue Sep 24 01:22:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 24 Sep 2024 01:22:25 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v5]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <DJ2V92KNbRZLLrpFTDMMZcd9J9gVAlmL_3DYx6DpSgQ=.f952d335-8512-48c9-ba48-a6783829d845@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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:

 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @liach and @cl4es comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @dholmes-ora review comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Do not use system property to limit usage to only CDS static dumps
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - ... and 1 more: https://git.openjdk.org/jdk/compare/34badfeb...b383d24b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/1c98bfab..b383d24b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=03-04

  Stats: 174327 lines in 1399 files changed: 158717 ins; 8139 del; 7471 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From swen at openjdk.org  Tue Sep 24 01:33:04 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 01:33:04 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod [v2]
In-Reply-To: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
Message-ID: <pjuqzHMJ35OsKPS6HttYSYeAAC3_2o3jiJC3YdTXr4M=.935cd126-4206-4ae2-ac77-35c317f274c0@github.com>

> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 291

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21137/files
  - new: https://git.openjdk.org/jdk/pull/21137/files/e0d4e0ad..ba35444b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21137&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21137&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21137/head:pull/21137

PR: https://git.openjdk.org/jdk/pull/21137

From jpai at openjdk.org  Tue Sep 24 01:50:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 01:50:39 GMT
Subject: RFR: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow [v9]
In-Reply-To: <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
 <ypXqI818K_naz3eL8kBsVZyGC1Ridwm7n_5QqXusPDY=.a72ee413-e87e-41c2-837a-d0a412586ab6@github.com>
Message-ID: <PST1OmmfvJUOmS10LbN_H-GPkJ5zSzjP2rrv5gev1ec=.017ca349-f4c6-4226-a5d3-339696888bbc@github.com>

On Mon, 23 Sep 2024 04:53:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
>> 
>> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
>> 
>> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
>> 
>> No new tests have been introduced in this PR and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - David's review for code comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - David's review for code comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - David's review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thank you all for the reviews and the help with this cleanup. I'll go ahead with the integration now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20997#issuecomment-2369943423

From jpai at openjdk.org  Tue Sep 24 01:50:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 01:50:40 GMT
Subject: Integrated: 8340114: Remove outdated SelectVersion() function from the
 launcher and update the code comments explaining the code flow
In-Reply-To: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
References: <8NEWS0q-apyZdqQUxdH4wWiPO_KzGoiOkYmX857NdEo=.b2d65ccd-6d2d-4f39-9a3b-c669b72ad789@github.com>
Message-ID: <eiyKL3q2HxufxMtKp1qhIf3ShhgkFyttPBaxFSctNRg=.7706adb6-b64e-4c90-9ebb-d9183d0cd173@github.com>

On Fri, 13 Sep 2024 12:29:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the (internal) `SelectVersion()` function from the java launcher and also update the code comments in the launcher to match the current implementation?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the `SelectVersion()` function in the launcher used to be relevant when JRE selection was a feature. That feature has been removed since Java 9 https://bugs.openjdk.org/browse/JDK-8058407. The SelectVersion() in its current form isn't relevant anymore and can be removed.
> 
> While at it, it was noticed that the current "flowchart" code comments in the launcher which attempts to explain the flow in the launcher code are outdated. The commit in this PR updates those comments for macosx and unix implementation. The windows variant doesn't have a "flowchart", but it too deserves a high level comment explaining this flow. I haven't updated the windows variant in this PR because that does a few additional things, which I need to review and understand better. I plan to take that up in a future change.
> 
> An existing `test/jdk/tools/launcher/MultipleJRERemoved.java/MultipleJRERemoved` test had to be updated due to the changes in this PR. That test was launching `java` (once) with 3 unsupported JRE selection options and was expecting 3 error messages (one each for the unsupported option) for that single launch. With the change in this PR, we don't accumulate and throw all those 3 errors and instead we fail fast for any of these 3 unsupported JRE selection options. The fail fast implementation matches what we do with other similar unsupported options. The test had to be updated to not expect all 3 errors message in a single launch and instead expect to find one of those error messages. Given what this test is for, and the fact that JRE version selection options (rightly) continue to raise an error after this change, I think, an update to that test should be OK.
> 
> No new tests have been introduced in this PR and tier testing is currently in progress.

This pull request has now been integrated.

Changeset: 40cde003
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40cde003e8061a0eb6b0214d5a44325c3d55cdc6
Stats:     744 lines in 8 files changed: 89 ins; 471 del; 184 mod

8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow

Reviewed-by: dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20997

From duke at openjdk.org  Tue Sep 24 01:51:56 2024
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 24 Sep 2024 01:51:56 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v3]
In-Reply-To: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
References: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
Message-ID: <HYVQI2z8Y6HmO61Oom1GAYc5pqTnzY-teyONFWMcMFY=.01a4daa8-1ef2-4541-a76d-25ec0f9cb015@github.com>

> 8340553: ZipEntry field validation does not take into account the size of a CEN header

Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:

  8340553: ZipEntry field validation does not take into account the size of a CEN header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21147/files
  - new: https://git.openjdk.org/jdk/pull/21147/files/7441bf02..0f1d7237

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21147&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21147&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21147/head:pull/21147

PR: https://git.openjdk.org/jdk/pull/21147

From jpai at openjdk.org  Tue Sep 24 01:54:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 01:54:36 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v5]
In-Reply-To: <BpGfUItTokUXYypzo7ni4ZankbQqbbinPc8vQn4Mk58=.37a15287-7619-45b0-966d-45c8904cb59a@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <BpGfUItTokUXYypzo7ni4ZankbQqbbinPc8vQn4Mk58=.37a15287-7619-45b0-966d-45c8904cb59a@github.com>
Message-ID: <UBFTkZLK_8P4hnxLZHQE51buDgJsuaKFADssP10ySRg=.ccc34c13-6106-44a7-8956-6a12414085af@github.com>

On Mon, 23 Sep 2024 16:29:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: Modify "More than one instance" paragraphs and convert to API notes

This still looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20320#pullrequestreview-2323833880

From jpai at openjdk.org  Tue Sep 24 02:09:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 02:09:34 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v3]
In-Reply-To: <HYVQI2z8Y6HmO61Oom1GAYc5pqTnzY-teyONFWMcMFY=.01a4daa8-1ef2-4541-a76d-25ec0f9cb015@github.com>
References: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
 <HYVQI2z8Y6HmO61Oom1GAYc5pqTnzY-teyONFWMcMFY=.01a4daa8-1ef2-4541-a76d-25ec0f9cb015@github.com>
Message-ID: <czmWv46HQLec2MLhJ9HmUHm7KD0D2GY_cxKGSrD_dqA=.ebfbbd8c-aadc-4c5e-ab8c-9ffcd636f637@github.com>

On Tue, 24 Sep 2024 01:51:56 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> 8340553: ZipEntry field validation does not take into account the size of a CEN header
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340553: ZipEntry field validation does not take into account the size of a CEN header

Hello @Korov, Lance is already working on this change and is planning to open a PR for the change shortly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21147#issuecomment-2369964776

From jpai at openjdk.org  Tue Sep 24 02:10:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 02:10:43 GMT
Subject: RFR: 8340596: Remove dead code from RequiresSetenv function in
 java.base/unix/native/libjli/java_md.c
In-Reply-To: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>
References: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>
Message-ID: <cdEukAwC-JCbb9k7LTSQf3pnZ6Zm-nkd44R27mE4oDM=.6fc585ff-c100-4779-8ced-7374eb2e65c9@github.com>

On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which removes dead code from the `RequiresSetenv()` function?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a left-over from the changes in https://bugs.openjdk.org/browse/JDK-8244224.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

Thank you David for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21125#issuecomment-2369965289

From jpai at openjdk.org  Tue Sep 24 02:10:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 02:10:44 GMT
Subject: Integrated: 8340596: Remove dead code from RequiresSetenv function in
 java.base/unix/native/libjli/java_md.c
In-Reply-To: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>
References: <mRzsth_yE6XknGzy1KNNIJyljupLVjnwK2OeKyQgkwA=.e64db10e-2d45-4eaa-a049-aa1c1fa6fb80@github.com>
Message-ID: <VQ8TYFFOWTJnWfPV7qI8kn4DZRWKDfN4GPH0_jKaSaY=.6ab1f5bd-d19a-4288-8467-537b31b26272@github.com>

On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which removes dead code from the `RequiresSetenv()` function?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a left-over from the changes in https://bugs.openjdk.org/browse/JDK-8244224.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

This pull request has now been integrated.

Changeset: 865d99f6
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/865d99f63475799b9a0503a3dcc21a7534b014d1
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8340596: Remove dead code from RequiresSetenv function in java.base/unix/native/libjli/java_md.c

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/21125

From duke at openjdk.org  Tue Sep 24 02:58:42 2024
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 24 Sep 2024 02:58:42 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v3]
In-Reply-To: <czmWv46HQLec2MLhJ9HmUHm7KD0D2GY_cxKGSrD_dqA=.ebfbbd8c-aadc-4c5e-ab8c-9ffcd636f637@github.com>
References: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
 <HYVQI2z8Y6HmO61Oom1GAYc5pqTnzY-teyONFWMcMFY=.01a4daa8-1ef2-4541-a76d-25ec0f9cb015@github.com>
 <czmWv46HQLec2MLhJ9HmUHm7KD0D2GY_cxKGSrD_dqA=.ebfbbd8c-aadc-4c5e-ab8c-9ffcd636f637@github.com>
Message-ID: <min7DhpbXsk-Xi15bEV2Bo6_fW45QrDdHHUm0N40Cvs=.4131f65a-3ead-424b-afc0-4bdbe621ca22@github.com>

On Tue, 24 Sep 2024 02:06:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello @Korov, Lance is already working on this change and is planning to open a PR for the change shortly.

OK, thanks for replay!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21147#issuecomment-2370010562

From duke at openjdk.org  Tue Sep 24 02:58:43 2024
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 24 Sep 2024 02:58:43 GMT
Subject: Withdrawn: 8340553: ZipEntry field validation does not take into
 account the size of a CEN header
In-Reply-To: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
References: <NLM9n8IxQqz_HQWTAjMrF01ir8BWl3oUdp0E1KHCJSs=.c9cb1a5b-f937-4a3e-88c5-ad62c32329c8@github.com>
Message-ID: <D5k4IFjARDNN9HS4jo3ybYfkatIHRJjopHSmcrXcYFE=.aa890c02-3e86-4c6a-9fd6-17dccc987edb@github.com>

On Tue, 24 Sep 2024 00:21:57 GMT, Lei Zhu <duke at openjdk.org> wrote:

> 8340553: ZipEntry field validation does not take into account the size of a CEN header

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21147

From duke at openjdk.org  Tue Sep 24 03:39:36 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 24 Sep 2024 03:39:36 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <fdGHI439-IJOij1vJ17eN-KxFhpR9CnxdrqXzQtr0p0=.3bfe4ea4-d6ee-4cc0-922b-d087a6ab17ff@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
 <fdGHI439-IJOij1vJ17eN-KxFhpR9CnxdrqXzQtr0p0=.3bfe4ea4-d6ee-4cc0-922b-d087a6ab17ff@github.com>
Message-ID: <zMB_mSBiOZW6q7pMVD1dqOCFwebXiqHVrJTvNCSksJA=.120eae22-cec1-4dae-ab5e-ebe355adf27d@github.com>

On Tue, 24 Sep 2024 01:01:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> My testing passed.

Thank You Vladimir!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2370044599

From duke at openjdk.org  Tue Sep 24 03:39:37 2024
From: duke at openjdk.org (duke)
Date: Tue, 24 Sep 2024 03:39:37 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
Message-ID: <D1ER3lc1Yy-5cCVtvGxfhN_UZWUzfJl8MOhbfXuYUT0=.5a20c601-738f-4099-8fdb-f71e9455f3b7@github.com>

On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change ifdef from x86 to AMD64

@vamsi-parasa 
Your change (at version 4dc2e36a8a2897d0a39d30a5580b18fbd9e5baf5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2370047322

From duke at openjdk.org  Tue Sep 24 03:56:41 2024
From: duke at openjdk.org (duke)
Date: Tue, 24 Sep 2024 03:56:41 GMT
Subject: Withdrawn: 8250659: Clarify in ParameterizedType.getRawType() doc that
 only Class is returned
In-Reply-To: <t5grGPxpTMli38FUPJlLcpv0Iirx7-4jYdfC1wz79Ik=.b33f6727-d2cd-4ce0-8e59-7a25d9b451c3@github.com>
References: <t5grGPxpTMli38FUPJlLcpv0Iirx7-4jYdfC1wz79Ik=.b33f6727-d2cd-4ce0-8e59-7a25d9b451c3@github.com>
Message-ID: <uk8PXfqDo_l_Q7YGBmmHDWKKXiiXwOwIqPPUmMLHRYY=.00a2328f-08a0-48a7-acf5-8043d1a7e5ef@github.com>

On Mon, 1 Jul 2024 19:20:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> Clarify that only `Class` is returned for core reflection implementation, and the return type is `Type` to support other implementations, such as ones modeling unloaded or remote types.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19978

From duke at openjdk.org  Tue Sep 24 03:56:46 2024
From: duke at openjdk.org (duke)
Date: Tue, 24 Sep 2024 03:56:46 GMT
Subject: Withdrawn: 8306039: ParameterizedType.getOwnerType() documentation is
 incomplete about null result
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: <YG8U_gybq3T5pSnLqOxXROZYrFS2hj-iXqvnoNbCons=.4d014a0e-3c75-454f-a2ed-d0133fcbfb30@github.com>

On Mon, 1 Jul 2024 18:22:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> Clarify that `ParameterizedType.getOwnerType()` always return `null` in a few scenarios.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19977

From jpai at openjdk.org  Tue Sep 24 04:38:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 04:38:09 GMT
Subject: RFR: 8340717: Remove unused function declarations from java.c/java.h
 of the launcher
Message-ID: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>

Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?

The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8340717.

The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).

The data model related macros, being removed in this PR, are unused and no longer relevant.

No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

-------------

Commit messages:
 - 8340717: Remove unused function declarations from java.c/java.h of the launcher

Changes: https://git.openjdk.org/jdk/pull/21149/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21149&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340717
  Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21149.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21149/head:pull/21149

PR: https://git.openjdk.org/jdk/pull/21149

From dholmes at openjdk.org  Tue Sep 24 04:49:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Sep 2024 04:49:37 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v5]
In-Reply-To: <DJ2V92KNbRZLLrpFTDMMZcd9J9gVAlmL_3DYx6DpSgQ=.f952d335-8512-48c9-ba48-a6783829d845@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <DJ2V92KNbRZLLrpFTDMMZcd9J9gVAlmL_3DYx6DpSgQ=.f952d335-8512-48c9-ba48-a6783829d845@github.com>
Message-ID: <BGqmLN7UHLUIOGS6bX1kxhhg_uQlJcHimdlAcK9798E=.a7de8a68-29d0-478c-b4cf-a9ac991cafa0@github.com>

On Tue, 24 Sep 2024 01:22:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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:
> 
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/88db5df3...b383d24b

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2324018448

From jpai at openjdk.org  Tue Sep 24 04:52:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Sep 2024 04:52:39 GMT
Subject: RFR: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
In-Reply-To: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
References: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
Message-ID: <McW-qHcP7Q4a-rcxR7UeVtscXZcAXjj4dkbROm6fju8=.596cbc4f-25a8-4dbe-b596-b0d2a498d082@github.com>

On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).

Hello Amit, following the process noted at https://openjdk.org/guide/#problemlisting-jtreg-tests for problem listing, I have now added the `problemlist` label to https://bugs.openjdk.org/browse/JDK-8339216.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20960#issuecomment-2370148902

From amitkumar at openjdk.org  Tue Sep 24 04:58:38 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 24 Sep 2024 04:58:38 GMT
Subject: RFR: 8339980: [s390x] ProblemList
 jdk/java/util/zip/CloseInflaterDeflaterTest.java
In-Reply-To: <McW-qHcP7Q4a-rcxR7UeVtscXZcAXjj4dkbROm6fju8=.596cbc4f-25a8-4dbe-b596-b0d2a498d082@github.com>
References: <nIz60TZGeG8plokTPpwmMsSo75sWfVQuMLH0pm4UNi8=.d85b7388-9ff0-44b1-a3db-e413c9b16e24@github.com>
 <McW-qHcP7Q4a-rcxR7UeVtscXZcAXjj4dkbROm6fju8=.596cbc4f-25a8-4dbe-b596-b0d2a498d082@github.com>
Message-ID: <pzcppBhL6LRyIXx_I8PddKMXXPRMVHRt9b5GN-SNcb0=.1ede948d-acf3-40f4-a019-937240e897f0@github.com>

On Tue, 24 Sep 2024 04:49:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` on s390x. This change should be reverted while fixing [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
>
> Hello Amit, following the process noted at https://openjdk.org/guide/#problemlisting-jtreg-tests for problem listing, I have now added the `problemlist` label to https://bugs.openjdk.org/browse/JDK-8339216.

Hi @jaikiran, 

Just went through that guide. 

>Remember to always add a problemlist label in the JBS issue referenced in the ProblemList entry.

Sorry, I didn't know it. Thank for pointing it out. I will follow it in future :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20960#issuecomment-2370155347

From swen at openjdk.org  Tue Sep 24 05:04:19 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 05:04:19 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod [v3]
In-Reply-To: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
Message-ID: <s8gigRBCeXaP9w6E46q5fe9cYwSZ64rpffNYlGlOfA0=.3770cbfb-609c-4dae-97b5-bfe4bdd39836@github.com>

> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 283

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  reduce getFrame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21137/files
  - new: https://git.openjdk.org/jdk/pull/21137/files/ba35444b..ba1f9aa4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21137&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21137&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21137/head:pull/21137

PR: https://git.openjdk.org/jdk/pull/21137

From dholmes at openjdk.org  Tue Sep 24 05:09:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Sep 2024 05:09:35 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
Message-ID: <p_rRUuAYIri6ve8E-FKQzeqVQG2LRa5LL368xHYvcBc=.905f0ce3-a95b-43b8-bbae-2f812004c38b@github.com>

On Fri, 20 Sep 2024 18:16:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 481:

> 479:                     cf,
> 480:                     clf,
> 481:                     mainModule);

This was correctly aligned before, now it isn't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1772609469

From dholmes at openjdk.org  Tue Sep 24 05:24:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Sep 2024 05:24:43 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v5]
In-Reply-To: <0RDfQ1EaaC1aco8SnnkEiw7_TsCoDSS3TKT7Y0TdVvU=.b3e9c08e-1928-484f-956b-f9cc0bb8c5d7@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0RDfQ1EaaC1aco8SnnkEiw7_TsCoDSS3TKT7Y0TdVvU=.b3e9c08e-1928-484f-956b-f9cc0bb8c5d7@github.com>
Message-ID: <yRXR-_5weC1JehaHJN7bVLbkTZwXUHvZNEJPfpCIrZ8=.c97ec668-b5a0-4e3b-b420-b2fda4476c8c@github.com>

On Mon, 23 Sep 2024 17:33:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @macarte comments

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/cds/metaspaceShared.cpp line 677:

> 675:     // When the new -XX:AOTMode=create flag is used, we can't return
> 676:     // to the JLI launcher, as the launcher will fail when trying to
> 677:     // run the main class, which is not what we want.

I actually find the original more clear - we have a new flag that we check and act upon. The "!old flag" seems an awkward way of saying "new flag".

-------------

PR Review: https://git.openjdk.org/jdk/pull/20516#pullrequestreview-2324067454
PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1772620807

From dholmes at openjdk.org  Tue Sep 24 06:21:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Sep 2024 06:21:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v4]
In-Reply-To: <Cy0X1ZHkyrwd_MlorYBQTfbvjHNy2AwHzH6HupiVrWc=.db0b3e8e-8f19-427f-9b9e-1a66eb685e0a@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <Ft7DvxeKdG6qAy3iwGjwftyBUebtxvEhsIzJgQRet9M=.bc3400a7-2452-4100-8165-87fd40b43b0c@github.com>
 <Cy0X1ZHkyrwd_MlorYBQTfbvjHNy2AwHzH6HupiVrWc=.db0b3e8e-8f19-427f-9b9e-1a66eb685e0a@github.com>
Message-ID: <ckdC3v1nmkHGPU7tDopPwdIuK976entDrT0X9wfbE-U=.b786ab5c-2ea4-4a19-87e3-79dd01c844b2@github.com>

On Mon, 23 Sep 2024 10:35:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> It is outside the scope of the javadoc text to state exactly why each restricted method is marked as such. 

I don't agree. I think restricted methods should document why they are restricted if it is not patently obvious.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2370288833

From alan.bateman at oracle.com  Tue Sep 24 06:28:22 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Sep 2024 07:28:22 +0100
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
Message-ID: <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>

On 23/09/2024 20:35, Rafael Winterhalter wrote:
> So I tracked down the discrepancy to a changing default for 
> URLClassLoader compared to JarFile. URLClassLoader resolves resources 
> to the "versions" folder for Java 9 and later, even without code 
> changes. This is not the case for JarFile where the relevant version 
> needs to be passed to a new constructor that is introduced in Java 9, 
> requiring code changes.

A lot of the direct usages of JarFile will be tools rather than custom 
class loaders so it was important that it be opt-in for this cohort. The 
exploration into compatibility and migration for MR JARs was 8-10 years 
ago. Looking at it now I don't think other defaults would have worked.

In the API docs "Implementation Note" you'll see that system property 
jdk.util.jar.enableMultiRelease can be set to "force" as a migration 
aid, maybe it will be useful here.



>
> This creates a new problem to me however: I can look up a 
> META-INF/versions resource in a multi-release jar, when using a class 
> loader, no matter the JVM version. I can however not look up the 
> original "non-META-INF" resource. I have been browsing the source 
> code, and this seems to be impossible, is that right? This again 
> brings me back to my original suggestion. Should there be a method in 
> ClassLoader (and JarFile) that allows locating a resource for a given 
> version? In code instrumentation tools, mostly for build, but also for 
> agents, it can be rather essential to query class file stores for 
> specific versions.
>
> I learned in the process that multi-release jars can contain anything, 
> not only classes. Therefore, I wonder if adding a method like the 
> following would be reasonable?
>
> public InputStream getResourceAsStream(String name, Runtime.Version 
> version) {
> ? return getResourceAsStream(name);
> }
>
> This would allow MR-aware class loaders an option to expose resources 
> independently of the current JVM version.
>
ClassLoader is abstracted away from where the resources are loaded from. 
So a different level from MR JARs.

I think it would be useful for the discussion if you could say more 
about this custom class loader is. Does it extend URLClassLoader, does 
it use JarFile directly, ... From the mails so far it sounds like there 
is something in the picture that is "MR JAR unaware" but it reading 
resources from a MR JAR. It sounds like some operations are locating 
resources in the base section and some in the versioned section.

-Alan

From epeter at openjdk.org  Tue Sep 24 06:39:41 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 24 Sep 2024 06:39:41 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v19]
In-Reply-To: <KC5Z--UoI5bQj9T3KWD-Nj3CvHqIlyHKpYpkVp_6wCE=.305930b1-4591-4fbc-a14d-7e93b53993f1@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <KC5Z--UoI5bQj9T3KWD-Nj3CvHqIlyHKpYpkVp_6wCE=.305930b1-4591-4fbc-a14d-7e93b53993f1@github.com>
Message-ID: <MXnTWUZOt5YeJzjIT6pIt2Us2R032easjaNHTufEVzo=.cd627c50-d6bd-433f-a70a-24453020a3cb@github.com>

On Mon, 23 Sep 2024 23:23:12 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 incrementally with one additional commit since the last revision:
> 
>   fix build error

FYI: I have not forgotten this work. I'm going on a 3 week vacation now, and hope to finish the `MergeStores` for `Unsafe` cases somewhere after that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2370317194

From alanb at openjdk.org  Tue Sep 24 06:54:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Sep 2024 06:54:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
 <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
 <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>
 <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>
Message-ID: <1OIu-oVRoJPvJE72Tdh6o7q2uHU0iD2XfPvGkfVCWoE=.b64341b7-ad41-4344-b26d-465de03eed3f@github.com>

On Mon, 23 Sep 2024 12:06:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.
>> 
>> I think saying 'no caller class on the stack' has the same effect though, unless someone knows how the implementation works (which may not be unreasonable), and is aware of the scenario where a java method is called from a new native thread. I thought it would look cleaner to have this be more 'explicitly unspecified' instead. But, maybe having something (vague or not), is better than nothing...
>
>> It is documented by the CS JEP: https://openjdk.org/jeps/176
> 
> I read the JEP, but it only refers to `sun.reflect.Reflection.getCallerClass`, which is an internal API that I don't expect external users to know about/understand.
> 
> To be clear: I don't think we should explain exactly how CS methods determine the caller. IMO, the fact that this is implemented using a stack walk is an implementation detail that users shouldn't have to know about (and it seems plausible for VM implementations to use other mechanisms). Or at least, that's what I would _like_ to think.
> 
> In lieu of that, I think it would be better to say that: in general (depending on the VM impl) there may be cases in which the caller can not be determined, and then as an example explicitly enumerate the cases in which the caller class can not be determined by the reference implementation. That explanation can then be linked to from the CS methods.

The "stack" is exposed in the API with StackWalker, Thread::getStackTrace and other APIs. For CS and restricted methods then I think we are trying to convey that there are no Java frames on the caller stack. Several existing CS APIs document the case where there is "no caller frame on the stack". This is mostly to cover the case where a CS method is invoked from a JNI attached thread. If there are native frames sandwiched between Java frames and a CS method then the intention was that these methods use the Java frame for the check, but that is hard to specify and it sounds like we have to re-visit this a bit.

For now, I think the proposed wording in this PR is okay. There are clearly some follows up needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1772732643

From alanb at openjdk.org  Tue Sep 24 06:59:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Sep 2024 06:59:37 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v4]
In-Reply-To: <ckdC3v1nmkHGPU7tDopPwdIuK976entDrT0X9wfbE-U=.b786ab5c-2ea4-4a19-87e3-79dd01c844b2@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <Ft7DvxeKdG6qAy3iwGjwftyBUebtxvEhsIzJgQRet9M=.bc3400a7-2452-4100-8165-87fd40b43b0c@github.com>
 <Cy0X1ZHkyrwd_MlorYBQTfbvjHNy2AwHzH6HupiVrWc=.db0b3e8e-8f19-427f-9b9e-1a66eb685e0a@github.com>
 <ckdC3v1nmkHGPU7tDopPwdIuK976entDrT0X9wfbE-U=.b786ab5c-2ea4-4a19-87e3-79dd01c844b2@github.com>
Message-ID: <tQo4oEOo_0M_iLJ7Nv4bpJ9XjBdYa_9yRTZlBV2BfHA=.717f120b-02db-40e8-a47a-599bcef3a0ef@github.com>

On Tue, 24 Sep 2024 06:19:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > It is outside the scope of the javadoc text to state exactly why each restricted method is marked as such.
> 
> I don't agree. I think restricted methods should document why they are restricted if it is not patently obvious.

I think you are arguing for an API note in each of these methods to document the rationale for why they are restricted. I don't think it needs to be done here, that is, API notes can be added separately, as needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2370349351

From alanb at openjdk.org  Tue Sep 24 06:59:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Sep 2024 06:59:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
Message-ID: <-4ipt7nPe7F3PvDo02nUTUZqVUHNUGzi7M4-h5YzTrM=.179a1d4a-0121-4893-8118-bfdb39661677@github.com>

On Mon, 23 Sep 2024 21:06:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc test failure

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2324246395

From dholmes at openjdk.org  Tue Sep 24 07:02:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Sep 2024 07:02:38 GMT
Subject: RFR: 8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from
 Windows coding
In-Reply-To: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
References: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
Message-ID: <poQkUymXQ8UqSp4C6LSZKuf97ha-GW0PMhQ_fqp9nCM=.c43ab92f-a7f3-4794-aadd-8e7a13375cd3@github.com>

On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any more for a very long time in OpenJDK.

Filed [JDK-8340731](https://bugs.openjdk.org/browse/JDK-8340731) for HS cleanup

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21130#issuecomment-2370355272

From alanb at openjdk.org  Tue Sep 24 07:02:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Sep 2024 07:02:38 GMT
Subject: RFR: 8340717: Remove unused function declarations from
 java.c/java.h of the launcher
In-Reply-To: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
References: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
Message-ID: <xwmSRe7_Sc-xz_ujM_rixTk2v_MKU6opYvWeeVyr4iY=.463b3c3e-083b-4aa7-92a3-cc115593cb0a@github.com>

On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?
> 
> The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8194937.
> 
> The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).
> 
> The data model related macros, being removed in this PR, are unused and no longer relevant.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21149#pullrequestreview-2324252827

From dholmes at openjdk.org  Tue Sep 24 07:06:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Sep 2024 07:06:35 GMT
Subject: RFR: 8340717: Remove unused function declarations from
 java.c/java.h of the launcher
In-Reply-To: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
References: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
Message-ID: <BwnMNQYRgcindCc3ZwDg4w-tbKWLRE8M2xFW0TPClhg=.e3e003fa-700d-4eb6-b760-7bedacb0fb00@github.com>

On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?
> 
> The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8194937.
> 
> The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).
> 
> The data model related macros, being removed in this PR, are unused and no longer relevant.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

LGTM!

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21149#pullrequestreview-2324259648

From jbhateja at openjdk.org  Tue Sep 24 07:10:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Sep 2024 07:10:24 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/31a58642..42ca80c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=11-12

  Stats: 225 lines in 41 files changed: 25 ins; 82 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From mbaesken at openjdk.org  Tue Sep 24 07:22:35 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 24 Sep 2024 07:22:35 GMT
Subject: RFR: 8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from
 Windows coding
In-Reply-To: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
References: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
Message-ID: <R3gwfC7BZMBBSIwWpuLxsxkJ1koNAiuGS0tE3avyPYE=.31e17141-8154-42a4-bd0e-f28c08ad965e@github.com>

On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any more for a very long time in OpenJDK.

some wget failed in the Windows build, unrelated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21130#issuecomment-2370397221

From mbaesken at openjdk.org  Tue Sep 24 07:25:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 24 Sep 2024 07:25:42 GMT
Subject: Integrated: 8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from
 Windows coding
In-Reply-To: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
References: <iD2NkZ4QZaueEFEuihXlD17AADiB3aAcSytGTP4U_xQ=.b79edc3e-81c4-4d66-af47-ed6bab389ccc@github.com>
Message-ID: <ghX6FIOyCaeTJEUeV9AXd8F5wOkaQFOQc03usHbk210=.f0eaff1a-551e-471b-bfdc-1d2f04bf4547@github.com>

On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any more for a very long time in OpenJDK.

This pull request has now been integrated.

Changeset: 9176f681
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9176f6810ef914579b8ca8e3bc20a0fdf3a934c8
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from Windows coding

Reviewed-by: alanb, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/21130

From rotanolexandr842 at gmail.com  Tue Sep 24 09:13:27 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Tue, 24 Sep 2024 12:13:27 +0300
Subject: Range API
In-Reply-To: <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
 <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
Message-ID: <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>

As part of the redesigning  process , I am researching whether or not there
are use cases that require asserting that the range is exactly
half-bounded. This is important because I plan to switch to
BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime
checks: Here is what I gathered for now.

- *Date/Time Handling (Historical or Forecast Data)*: When dealing with
events that started at a specific time but have no known end (e.g.,
open-ended employment contracts or ongoing subscriptions)
- *Stream Processing (Real-time Event Streams)*: In real-time systems, you
might process data that has a start time but no defined end, such as
monitoring a live video feed or logging system. The range is bounded at the
start and unbounded at the end as more data will continuously arrive.
- *Data Pagination (Fetch Until Condition)*: When implementing pagination,
sometimes you might want to fetch items starting from a specific index up
to an unbounded limit (e.g., fetching all items after a certain point until
memory runs out or a condition is met).
- *Auditing and Monitoring*: In systems where audit trails or logging data
should capture all events after a certain point (bounded start) with no
foreseeable end (unbounded end), such as monitoring changes to records in a
database starting from a fixed timestamp.
- *Scientific or Statistical Ranges*: When modeling physical systems or
statistical ranges, you might want to capture measurements that begin at a
known threshold but theoretically have no upper or lower bound. For
example, recording temperature data starting at absolute zero and
increasing without any known upper limit.
- *Inventory or Resource Allocation*: Resource allocation policies, such as
those for virtual machines, may be based on known minimum allocation
thresholds but have flexible or unbounded resource caps, depending on
availability.

I am writing to ask whether anyone who worked with such systems could
confirm/deny that those are real use cases. If so, would it be satisfying
enough to assert one-way unboundness with instanceof checks, i.e. range
instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange).
Would appreciate any feedback.

Best regards

On Tue, Sep 24, 2024 at 12:02?AM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> But do those two use cases really need an abstraction? Is there really
>> value in a Range interface?
>> Given the two classes above, which are IMO candidates for the JDK, they
>> work fine as isolated value types without a generalized abstraction.
>
>
> I see this a bit differently. In the examples you provided, there are
> basically no methods that would somehow indicate that Interval is something
> more than generic Range<Instant> besides toDuration(), and same goes for
> LocalDateRange. Therefore, I see generic ranges not as "abstracting"
> ranges, but rather adapting them for the general case. Range<Instant> and
> Interval are roughly identical, with differences easily coverable by few
> static methods.
>
> Similarly, I'm not sure what a Range value type would accomplish. Don't
>> get me wrong - if fully integrated into the language, with literals and
>> looping syntax there might be a case, but we are a long way from that.
>
>
> Well, every feature started somewhere. There is clearly a demand for range
> support, both numeric, chronological, and potentially many others. Amber is
> considering integrating ranges as patterns, so anyway internal
> representation will be needed.
>
> Sorry to be a bit down given the massive effort made here, but the harsh
>> truth is that I've yet to see a "Range" API that I like, and I especially
>> find mixing bounded/unbounded and inclusive/exclusive gets complicated and
>> unpleasant very fast.
>
>
> Your opinion is valuable too. I am not pushing on integrating this
> changes, PR mostly serves research purpose, and final form could (and most
> likely will) differ a lot from the current state of API.
>
> Ranges are indeed not easy to model, they always could use some
> syntax-level dsl. If the demand shows to be high enough, this may also be
> the subject of discussion. Nevertheless, ranges in general are really
> popular. Chronological ranges are one of the most common business object
> attributes, numeric ranges could be useful for research and visualization
> etc. For now, I will continue on evolving the API, to see if it is possible
> to arrive at the point where the API is smooth enough to become a candidate.
>
> PS: Regarding chronological ranges specifically, this was my motivation in
> the first place (
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125271.html)..I
> was initially a fan of nominal date and time ranges, but when I started
> modeling the API, I discovered that, surprisingly, there is little to none
> tdatetime-specific operations that could be made on ranges. Therefore, I
> came to the conclusion that ranges generalize too well to miss on this.
> Some people here argue it is too strict to oblige range elements to be
> comparable, let alone chronological types.
>
> On Mon, Sep 23, 2024 at 11:24?PM Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
>> I've always found the generic concept of a "range" tricky to express
>> in a sensible API. When authoring Joda-Time and java.time I avoided it
>> as much as possible.
>>
>> ThreeTen-Extra has two classes - Interval and LocalDateRange - which
>> cover the two main use cases.
>>
>> https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/package-summary.html
>>
>> But do those two use cases really need an abstraction? Is there really
>> value in a Range interface?
>> Given the two classes above, which are IMO candidates for the JDK,
>> they work fine as isolated value types without a generalized
>> abstraction.
>>
>> Similarly, I'm not sure what a Range value type would accomplish.
>> Don't get me wrong - if fully integrated into the language, with
>> literals and looping syntax there might be a case, but we are a long
>> way from that. (ie. some language designs are built around ranges as a
>> first class concept, but Java isn't, and I have doubts that it would
>> be a good fit to try and pivot that way now.) In particular, I
>> struggle with a generified Range type - it just "feels wrong" to me.
>>
>> Sorry to be a bit down given the massive effort made here, but the
>> harsh truth is that I've yet to see a "Range" API that I like, and I
>> especially find mixing bounded/unbounded and inclusive/exclusive gets
>> complicated and unpleasant very fast. And that is before you consider
>> discrete versus continuous.
>> Stephen
>>
>>
>> On Sun, 22 Sept 2024 at 20:02, Olexandr Rotan
>> <rotanolexandr842 at gmail.com> wrote:
>> >
>> > Hello everyone! I am writing here today to invite everyone to
>> participate in the discussion regarding the Range APi proposal I have made
>> into JDK. Here is the pull request link:
>> https://github.com/openjdk/jdk/pull/21122, and PR text:
>> >
>> > This pull request describes the methods of the Range<T> interface. The
>> Range<T> interface represents a bounded or unbounded range. (From now on,
>> range, span and interval are used interchangeably, but docs only use
>> "range")
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/6f792510/attachment.htm>

From asotona at openjdk.org  Tue Sep 24 09:34:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 24 Sep 2024 09:34:38 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v7]
In-Reply-To: <AMxoGDMN6-WeZxl4C0YAoghVXdljlPU1txA5o3YYnK4=.429a82d9-6490-44e4-aec9-c239b8d6bc58@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <AMxoGDMN6-WeZxl4C0YAoghVXdljlPU1txA5o3YYnK4=.429a82d9-6490-44e4-aec9-c239b8d6bc58@github.com>
Message-ID: <NLn_dx2OkThf8yAtHIXFTvvoY9kYeVqnIJeGusjcSYc=.ba06ab7d-b4b4-4c52-9e5d-7e45f48be6dd@github.com>

On Mon, 23 Sep 2024 21:42:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Move raw opcodes to impl only
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - omission in tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Rename constants at new locations, link to related factories, cp tag constant names
>  - Fix compile errors
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e97f0fe1...8b03ad17

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20773#pullrequestreview-2324671617

From shade at openjdk.org  Tue Sep 24 09:57:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Sep 2024 09:57:39 GMT
Subject: RFR: 8340717: Remove unused function declarations from
 java.c/java.h of the launcher
In-Reply-To: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
References: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
Message-ID: <E8yKj_KdpZv8wZdjtc2eQtxHUNmI8KM1otjUjgVUsPU=.3ffa0b63-da7c-4c97-b385-1858f5d6271b@github.com>

On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?
> 
> The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8194937.
> 
> The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).
> 
> The data model related macros, being removed in this PR, are unused and no longer relevant.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21149#pullrequestreview-2324730406

From rafael.wth at gmail.com  Tue Sep 24 10:43:44 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 24 Sep 2024 12:43:44 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
Message-ID: <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>

Without getting lost in specifics:

Byte Buddy allows to transform classes and to store the transformed state.
Increasingly, this is done at build time to reduce start up costs and to
support AOT compilation. Java agents are the more common option still, but
I notice a shift to build time instrumentation, also because of dynamic
attach becoming less accessible. One consequence is that the building JVM
might not be of the same version as the executing JVM.

With this in mind, class files are read from either:
- A folder
- A JAR file
- A ClassLoader (getResourceAsStream)

In build tools, the last option is rather uncommon, but it exists. I can
only assume that the people that requested this use case have good enough
reasons for this (probably because URLs are remote and the logic to fetch
them is wired into a loader implementation, I am guessing, though).

If the build plugin now wants to create instrumented versions of class
files for a Java 17 JVM, while the build is run on a Java 21 JVM, I can
support this for JAR files, for folders, but I cannot fetch the adequate
resource when the underlying resource accessor is a class loader. I do not
think that I can work around this, or do I overlook something?

Thanks, Rafael

Alan Bateman <alan.bateman at oracle.com> schrieb am Di., 24. Sept. 2024,
08:28:

> On 23/09/2024 20:35, Rafael Winterhalter wrote:
> > So I tracked down the discrepancy to a changing default for
> > URLClassLoader compared to JarFile. URLClassLoader resolves resources
> > to the "versions" folder for Java 9 and later, even without code
> > changes. This is not the case for JarFile where the relevant version
> > needs to be passed to a new constructor that is introduced in Java 9,
> > requiring code changes.
>
> A lot of the direct usages of JarFile will be tools rather than custom
> class loaders so it was important that it be opt-in for this cohort. The
> exploration into compatibility and migration for MR JARs was 8-10 years
> ago. Looking at it now I don't think other defaults would have worked.
>
> In the API docs "Implementation Note" you'll see that system property
> jdk.util.jar.enableMultiRelease can be set to "force" as a migration
> aid, maybe it will be useful here.
>
>
>
> >
> > This creates a new problem to me however: I can look up a
> > META-INF/versions resource in a multi-release jar, when using a class
> > loader, no matter the JVM version. I can however not look up the
> > original "non-META-INF" resource. I have been browsing the source
> > code, and this seems to be impossible, is that right? This again
> > brings me back to my original suggestion. Should there be a method in
> > ClassLoader (and JarFile) that allows locating a resource for a given
> > version? In code instrumentation tools, mostly for build, but also for
> > agents, it can be rather essential to query class file stores for
> > specific versions.
> >
> > I learned in the process that multi-release jars can contain anything,
> > not only classes. Therefore, I wonder if adding a method like the
> > following would be reasonable?
> >
> > public InputStream getResourceAsStream(String name, Runtime.Version
> > version) {
> >   return getResourceAsStream(name);
> > }
> >
> > This would allow MR-aware class loaders an option to expose resources
> > independently of the current JVM version.
> >
> ClassLoader is abstracted away from where the resources are loaded from.
> So a different level from MR JARs.
>
> I think it would be useful for the discussion if you could say more
> about this custom class loader is. Does it extend URLClassLoader, does
> it use JarFile directly, ... From the mails so far it sounds like there
> is something in the picture that is "MR JAR unaware" but it reading
> resources from a MR JAR. It sounds like some operations are locating
> resources in the base section and some in the versioned section.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/1121de45/attachment.htm>

From jwaters at openjdk.org  Tue Sep 24 11:07:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 24 Sep 2024 11:07:38 GMT
Subject: RFR: 8340717: Remove unused function declarations from
 java.c/java.h of the launcher
In-Reply-To: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
References: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
Message-ID: <-XYY9ANhE1OjyxyF3O27DnD8f_ZYEcpDg6D_mmEUoog=.bef842f7-25fc-48e8-bbda-98d75022c51f@github.com>

On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?
> 
> The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8194937.
> 
> The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).
> 
> The data model related macros, being removed in this PR, are unused and no longer relevant.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Looks trivial and good

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21149#pullrequestreview-2324883983

From eirbjo at gmail.com  Tue Sep 24 11:44:00 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 24 Sep 2024 13:44:00 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
Message-ID: <CA+pBWhsftw6PyZ1FmR-U46UR-3K+iuA3p7i3ZsqSEFWD1dTBNA@mail.gmail.com>

On Tue, Sep 24, 2024 at 12:44?PM Rafael Winterhalter <rafael.wth at gmail.com>
wrote:

> Without getting lost in specifics:
>
It is also possible to get very lost by lacking specifics :-)

> If the build plugin now wants to create instrumented versions of class
> files for a Java 17 JVM, while the build is run on a Java 21 JVM, I can
> support this for JAR files, for folders, but I cannot fetch the adequate
> resource when the underlying resource accessor is a class loader. I do not
> think that I can work around this, or do I overlook something?
>
Thanks, this narrows down your use case considerably and also explains why
you would be interested in loading resources of versions different than the
runtime version.

Does the class loader in question return JAR-form URLs? If that's the case,
you could use JarURLConnection.getJarFile() and use getInputStream to get
the versioned resource of choice:

ClassLoader loader = new URLClassLoader(new URL[] {zip.toUri().toURL()});
URL resource = loader.getResource(baseName);
if (resource.openConnection() instanceof JarURLConnection con) {
    try (var is = con.getJarFile().getInputStream(new ZipEntry(baseName))) {
        assertArrayEquals("base".getBytes(StandardCharsets.UTF_8),
                is.readAllBytes());
    }
}

Or just parse the URL to find the path to the JAR file and open it using
ZipFile/JarFile APIs.

Is the issue reported to Byte Buffy publicly available?

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/2c1b5026/attachment.htm>

From 1dropaflame at gmail.com  Tue Sep 24 12:29:40 2024
From: 1dropaflame at gmail.com (Anil)
Date: Tue, 24 Sep 2024 07:29:40 -0500
Subject: Shouldn't it be easier to turn a String into a stream of chars?
 (perhaps the String API needs a new method)
Message-ID: <CAG68Eh1tAXER5hVx_DGt1OtKAQwFH9p2Qk92mDZm4SXkEDHokA@mail.gmail.com>

I was trying to solve a puzzle (see post in JavaRanch
https://coderanch.com/t/784868/java/puzzling-partitioningBy-IntStream-compile-error
)
I found that String.chars() yields an IntStream.
Someone pointed out that to convert it into Characters, one has to do

  Stream<Character> sc = s.chars().mapToObj(n -> (char) n);

It should not take so many obscure steps like this to turn a String into a
stream of chars!
I feel the Java API needs another method

Stream<Character> String.asChars()

thanks,
Anil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/e6d50a65/attachment.htm>

From eirbjo at gmail.com  Tue Sep 24 12:42:27 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 24 Sep 2024 14:42:27 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+pBWhsftw6PyZ1FmR-U46UR-3K+iuA3p7i3ZsqSEFWD1dTBNA@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
 <CA+pBWhsftw6PyZ1FmR-U46UR-3K+iuA3p7i3ZsqSEFWD1dTBNA@mail.gmail.com>
Message-ID: <CA+pBWhtb6YMw5xjW4bhXZdgxz-pKFfDiODWd0OFL=G1Kt+XFQQ@mail.gmail.com>

On Tue, Sep 24, 2024 at 1:44?PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

> Does the class loader in question return JAR-form URLs? If that's the
> case, you could use JarURLConnection.getJarFile() and use getInputStream to
> get the versioned resource of choice:
>

If you also want to offload the version lookup logic to JarFile, re-open
the JarFile with the desired runtime version,  like in the following test:

@Test
public void readVersionedResourceFromClassLoader() throws IOException {
    // Base name of the class file resource looked up in this test
    String baseName = "com/example/HelloWorld.class";

    // Create a multi-release JAR file including a versioned entry
    Path zip = createMultiReleaseJar(baseName);

    // A class loader backed by the multi-release JAR file
    ClassLoader loader = new URLClassLoader(new URL[]
{zip.toUri().toURL()});

    // The version to get resources for
    Runtime.Version version = Runtime.Version.parse("17");

    URL resource = loader.getResource(baseName);

    if (resource != null && resource.openConnection() instanceof
JarURLConnection con) {
        File file = new File(con.getJarFile().getName());
        // Open a JarFile for the desired runtime version
        try (JarFile jf = new JarFile(file, true, ZipFile.OPEN_READ,
version)) {
            JarEntry entry = jf.getJarEntry(baseName);
            assertEquals(baseName, entry.getName());
            assertEquals("META-INF/versions/11/" + baseName,
entry.getRealName());
            try (var is = jf.getInputStream(entry)) {
                assertEquals("11", new String(is.readAllBytes()));
            }
        }
    }
}

private static Path createMultiReleaseJar(String baseName) throws
IOException {
    Path zip = Path.of("multi-release.zip");
    Manifest man = new Manifest();
    Attributes attrs = man.getMainAttributes();
    attrs.put(Attributes.Name.MANIFEST_VERSION, "1.0");
    attrs.put(Attributes.Name.MULTI_RELEASE, "true");
    try (JarOutputStream jo = new
JarOutputStream(Files.newOutputStream(zip), man)) {
        jo.putNextEntry(new ZipEntry("META-INF/versions/11/" + baseName));
        jo.write("11".getBytes(StandardCharsets.UTF_8));
        jo.putNextEntry(new ZipEntry(baseName));
        jo.write("base".getBytes(StandardCharsets.UTF_8));
    }
    return zip;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/72f21a1c/attachment-0001.htm>

From rafael.wth at gmail.com  Tue Sep 24 12:48:20 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 24 Sep 2024 14:48:20 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+pBWhsftw6PyZ1FmR-U46UR-3K+iuA3p7i3ZsqSEFWD1dTBNA@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
 <CA+pBWhsftw6PyZ1FmR-U46UR-3K+iuA3p7i3ZsqSEFWD1dTBNA@mail.gmail.com>
Message-ID: <CA+DM0Am7CQLhLjvjUR0AqEa0gd5UwP2hqtxXXd=t9fVXoSEn9Q@mail.gmail.com>

When the ClassLoader API is used in build plugins, this often serves as a
fallback to non-standardized class storage where the retrieval
implementation is bound to the ClassLoder API. I would have to guess but I
would not assume that many of them use a JarInputStream as a backing
mechanism. By my experience, custom class loaders typically load classes
via TCP.

One use case I remember is a class loader that queried a server which
loaded jars via a URLClassLoader and served class files on demand. In such
a case, it would also be relevant that the resource would be consistent
with the client JVM version, not the server one. Updating the server alone
would result in different resources. Of course, using JarFile to access
resources would be the better option here, but ideally one could adapt MR
jars without larger rewrites. URLClassLoder accepts URLs while JarFile
requires File, what might result in a non-trivial rewrite, for example if
there's multiple hoops.

I don't think this is a large issue either, rather an edge case, otherwise
I would have stumbled over this earlier. The main issue is that Java 8
always allows me to access META-INF resources and the original class file
via the ClassLoder API. Starting from Java 9, the original class file might
be shadowed and inaccessible. So a build might yield a different result
after updating the JDK, and currently I do not see a way to resolve this
backwards compatible. Therefore I was wondering if a new API should adress
this. In JarFile, you can iterate over all resources, including those that
are shadowed, at least. It is something like that that I am looking for.

As for a public issue: I recently had an unrelated issue on MR JARs in
builds what made me aware of this possibility of encountering MR jar files
through ClassLoader class file locators in build plugins, which is a
combination of two rare events that nobody complained about before. But I
could not point you to an old ticket.

Eirik Bj?rsn?s <eirbjo at gmail.com> schrieb am Di., 24. Sept. 2024, 13:44:

> On Tue, Sep 24, 2024 at 12:44?PM Rafael Winterhalter <rafael.wth at gmail.com>
> wrote:
>
>> Without getting lost in specifics:
>>
> It is also possible to get very lost by lacking specifics :-)
>
>> If the build plugin now wants to create instrumented versions of class
>> files for a Java 17 JVM, while the build is run on a Java 21 JVM, I can
>> support this for JAR files, for folders, but I cannot fetch the adequate
>> resource when the underlying resource accessor is a class loader. I do not
>> think that I can work around this, or do I overlook something?
>>
> Thanks, this narrows down your use case considerably and also explains why
> you would be interested in loading resources of versions different than the
> runtime version.
>
> Does the class loader in question return JAR-form URLs? If that's the
> case, you could use JarURLConnection.getJarFile() and use getInputStream to
> get the versioned resource of choice:
>
> ClassLoader loader = new URLClassLoader(new URL[] {zip.toUri().toURL()});
> URL resource = loader.getResource(baseName);
> if (resource.openConnection() instanceof JarURLConnection con) {
>     try (var is = con.getJarFile().getInputStream(new
> ZipEntry(baseName))) {
>         assertArrayEquals("base".getBytes(StandardCharsets.UTF_8),
>                 is.readAllBytes());
>     }
> }
>
> Or just parse the URL to find the path to the JAR file and open it using
> ZipFile/JarFile APIs.
>
> Is the issue reported to Byte Buffy publicly available?
>
> Thanks,
> Eirik.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/a9cf8a05/attachment.htm>

From alan.bateman at oracle.com  Tue Sep 24 13:23:44 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Sep 2024 14:23:44 +0100
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
Message-ID: <1df40152-d011-4629-a5b3-aeed667d9761@oracle.com>

On 24/09/2024 11:43, Rafael Winterhalter wrote:
>
> Without getting lost in specifics:
>
> Byte Buddy allows to transform classes and to store the transformed 
> state. Increasingly, this is done at build time to reduce start up 
> costs and to support AOT compilation. Java agents are the more common 
> option still, but I notice a shift to build time instrumentation, also 
> because of dynamic attach becoming less accessible. One consequence is 
> that the building JVM might not be of the same version as the 
> executing JVM.
>
> With this in mind, class files are read from either:
> - A folder
> - A JAR file
> - A ClassLoader (getResourceAsStream)
>
> In build tools, the last option is rather uncommon, but it exists. I 
> can only assume that the people that requested this use case have good 
> enough reasons for this (probably because URLs are remote and the 
> logic to fetch them is wired into a loader implementation, I am 
> guessing, though).
>
> If the build plugin now wants to create instrumented versions of class 
> files for a Java 17 JVM, while the build is run on a Java 21 JVM, I 
> can support this for JAR files, for folders, but I cannot fetch the 
> adequate resource when the underlying resource accessor is a class 
> loader. I do not think that I can work around this, or do I overlook 
> something?
>

Tooling that does static instrumentation leads itself to a --release N 
option. Assuming this isn't a training runs of sorts it's hard hard to 
picture a ClassLoader in that environment. How does the build tool now 
what to setup so that it matches the arrangement and visibility of 
runtime? Is it really a ClassLoader or something just locates the class 
bytes in the same way as a ClassLoader at runtime?

-Alan

From asotona at openjdk.org  Tue Sep 24 13:53:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 24 Sep 2024 13:53:39 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v5]
In-Reply-To: <dWPf46MgKHrJSG-8jg0d83AX-sWkIK2vMt-_Ox9mnR4=.79950cf6-f67d-4716-a9ec-5b79249f3727@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <dWPf46MgKHrJSG-8jg0d83AX-sWkIK2vMt-_Ox9mnR4=.79950cf6-f67d-4716-a9ec-5b79249f3727@github.com>
Message-ID: <GTvty19S4eiAGUWHsCgw7Q7CZ0UIa-qmxhYaGK746wo=.d7dfbb50-b71f-4f70-beaf-015a4cdbf587@github.com>

On Mon, 23 Sep 2024 22:23:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Fresh creation bench
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/e97f0fe1...7f79042a

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20667#pullrequestreview-2325349655

From eirbjo at openjdk.org  Tue Sep 24 13:59:56 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 24 Sep 2024 13:59:56 GMT
Subject: RFR: 8340684: Reading from an input stream backed by a closed ZipFile
 has no test coverage
Message-ID: <V_9qh9hA7lJHKD0-gFN-JObc8r3hs0ouVyATrcvmDdc=.a40afcd7-6b44-4667-b8ca-a193cd15bdeb@github.com>

Please review this PR which adds test coverage for the case of reading from an input stream obtained using`ZipFile:getInputStream` after the backing `ZipFile` has been closed. 

The unspecified but long-standing behavior for this unusual use case is to throw `IOException`, but this is not verified by current tests. Adding a test would help prevent regressions in this area.

The test is parameterized to excercise a variation of stored/deflated entries, and a variation of read behaviors before the `ZipFile` is closed.

-------------

Commit messages:
 - Add a test to verify exception behavior when reading from an input stream backed by a closed ZipFile.

Changes: https://git.openjdk.org/jdk/pull/21142/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340684
  Stats: 128 lines in 1 file changed: 128 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21142/head:pull/21142

PR: https://git.openjdk.org/jdk/pull/21142

From javalists at cbfiddle.com  Tue Sep 24 14:11:10 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 24 Sep 2024 07:11:10 -0700
Subject: Range API
In-Reply-To: <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
 <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
 <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>
Message-ID: <5320CD47-A9EB-44BE-994B-F296FC281D3A@cbfiddle.com>

I have another example: I have a datatype that represents a region of an audio track, for example, one tune in a medley of tunes. I allow the region to
specify both a start and end time, but the end time is optional (and mostly not used). When the end time is not specified, the region ends at the start of the next region, or at
the end of the track if there is no next region. The latter case is useful because the exact track length may not be known. The optionality of the end time
is not represented in the type system.

Having said that, I?m not sure that a general abstract interface would be useful for this example.

> On Sep 24, 2024, at 2:13?AM, Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:
> 
> As part of the redesigning  process , I am researching whether or not there are use cases that require asserting that the range is exactly half-bounded. This is important because I plan to switch to BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime checks: Here is what I gathered for now.
> 
> Date/Time Handling (Historical or Forecast Data): When dealing with events that started at a specific time but have no known end (e.g., open-ended employment contracts or ongoing subscriptions)
> Stream Processing (Real-time Event Streams): In real-time systems, you might process data that has a start time but no defined end, such as monitoring a live video feed or logging system. The range is bounded at the start and unbounded at the end as more data will continuously arrive.
> Data Pagination (Fetch Until Condition): When implementing pagination, sometimes you might want to fetch items starting from a specific index up to an unbounded limit (e.g., fetching all items after a certain point until memory runs out or a condition is met).
> Auditing and Monitoring: In systems where audit trails or logging data should capture all events after a certain point (bounded start) with no foreseeable end (unbounded end), such as monitoring changes to records in a database starting from a fixed timestamp.
> Scientific or Statistical Ranges: When modeling physical systems or statistical ranges, you might want to capture measurements that begin at a known threshold but theoretically have no upper or lower bound. For example, recording temperature data starting at absolute zero and increasing without any known upper limit.
> Inventory or Resource Allocation: Resource allocation policies, such as those for virtual machines, may be based on known minimum allocation thresholds but have flexible or unbounded resource caps, depending on availability.
> 
> I am writing to ask whether anyone who worked with such systems could confirm/deny that those are real use cases. If so, would it be satisfying enough to assert one-way unboundness with instanceof checks, i.e. range instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange). Would appreciate any feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/d8dbb9b8/attachment.htm>

From liach at openjdk.org  Tue Sep 24 14:30:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 14:30:45 GMT
Subject: Integrated: 8338546: Speed up
 ConstantPoolBuilder::classEntry(ClassDesc)
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <n_xnJBZBnbn6ztqI7qloHGHaypTLK_96TVnadMP3en8=.8fa1d717-6b7a-442a-abfe-166d8ca06aa1@github.com>

On Wed, 21 Aug 2024 22:27:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

This pull request has now been integrated.

Changeset: caa751c5
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/caa751c561f55bc59a6195a947d7b75515b5d2c0
Stats:     689 lines in 7 files changed: 594 ins; 42 del; 53 mod

8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

Reviewed-by: asotona, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20667

From mcimadamore at openjdk.org  Tue Sep 24 14:56:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 24 Sep 2024 14:56:19 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix paths to links

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/0e0944ed..e2326094

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From jvernee at openjdk.org  Tue Sep 24 14:56:19 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 24 Sep 2024 14:56:19 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
Message-ID: <0nx1E-YFlN9j2l4uRPbFfPhZ0FsX9c1G_VjUGG-OhSw=.11503b51-60fa-4c88-9fe2-972e40d0941a@github.com>

On Tue, 24 Sep 2024 14:53:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix paths to links

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2325555109

From jvernee at openjdk.org  Tue Sep 24 14:56:20 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 24 Sep 2024 14:56:20 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <1OIu-oVRoJPvJE72Tdh6o7q2uHU0iD2XfPvGkfVCWoE=.b64341b7-ad41-4344-b26d-465de03eed3f@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
 <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
 <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>
 <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>
 <1OIu-oVRoJPvJE72Tdh6o7q2uHU0iD2XfPvGkfVCWoE=.b64341b7-ad41-4344-b26d-465de03eed3f@github.com>
Message-ID: <2FnLGXf2S5arfbUC-uyno4Emiwx5MAKPAB6CM_Fo-PU=.42d335cf-e283-4d09-97ec-da820eedaf51@github.com>

On Tue, 24 Sep 2024 06:51:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For now, I think the proposed wording in this PR is okay. 

Yes, I agree what I'm suggesting is out of scope for this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1773524153

From jbhateja at openjdk.org  Tue Sep 24 15:09:41 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Sep 2024 15:09:41 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
Message-ID: <wpYstDulXwZD7iStdhS7YKPyx4Y6b0mgNi9P2g167Ho=.4259ceac-4299-454a-bd7b-1c83f1d511c7@github.com>

On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change ifdef from x86 to AMD64

Marked as reviewed by jbhateja (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20657#pullrequestreview-2325597060

From duke at openjdk.org  Tue Sep 24 15:14:47 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 24 Sep 2024 15:14:47 GMT
Subject: Integrated: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <lhzpLHNL6JHfI5ShlcC_IJZXJ4R4qITJ_qOiAxBSZhA=.6e42cdc0-150f-48c6-acc7-c12c72fb3f1c@github.com>

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

This pull request has now been integrated.

Changeset: 212e3293
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
URL:       https://git.openjdk.org/jdk/commit/212e32931cafe446d94219d6c3ffd92261984dff
Stats:     980 lines in 26 files changed: 970 ins; 0 del; 10 mod

8338694: x86_64 intrinsic for tanh using libm

Reviewed-by: kvn, jbhateja, sgibbons, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/20657

From ecki at zusammenkunft.net  Tue Sep 24 15:20:34 2024
From: ecki at zusammenkunft.net (Bernd)
Date: Tue, 24 Sep 2024 17:20:34 +0200
Subject: Shouldn't it be easier to turn a String into a stream of
 chars? (perhaps the String API needs a new method)
In-Reply-To: <CAG68Eh1tAXER5hVx_DGt1OtKAQwFH9p2Qk92mDZm4SXkEDHokA@mail.gmail.com>
References: <CAG68Eh1tAXER5hVx_DGt1OtKAQwFH9p2Qk92mDZm4SXkEDHokA@mail.gmail.com>
Message-ID: <5CA6D0B7-0EA9-2148-A929-757735D62A71@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/c2acf37e/attachment.htm>

From liach at openjdk.org  Tue Sep 24 15:28:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 15:28:41 GMT
Subject: RFR: 8340587: Optimize StackMapGenerator$Frame::checkAssignableTo
In-Reply-To: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
References: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
Message-ID: <IksN-OEQzPtR6BGEaTXVLDyGL7w4-Bhvm6qCk9nxaOo=.3533a6f2-07c8-4032-8235-fcfd7862ed27@github.com>

On Sun, 22 Sep 2024 13:20:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone instead of Array.copyOf to avoid compression and then expansion

Thanks for this cleanup! Tests pass.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21121#pullrequestreview-2325652447

From liach at openjdk.org  Tue Sep 24 15:38:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 15:38:40 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
Message-ID: <GsBtupOyA6ecuZdC2A_NZidUg7DS-mgDA3w9yCY9Y1w=.801d9772-4d7a-4e85-988d-a5291d03f35a@github.com>

On Sun, 22 Sep 2024 05:30:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
> 
> 1. DirectClassBuilder::build codeSize 361 -> 315
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
> 4. BufWriterImpl::writeU2 (forceinline)
> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
> 6. Util::writeList codSize 47 -> 42 (forceinline)

src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java line 208:

> 206: 
> 207:         // Now we can make the head
> 208:         head.writeLong((((long) ClassFile.MAGIC_NUMBER) << 32) | ((minorVersion & 0xFFFFL) << 16) | majorVersion);

Suggestion:

        head.writeLong((((long) ClassFile.MAGIC_NUMBER) << 32) | ((minorVersion & 0xFFFFL) << 16) | (majorVersion & 0xFFFFL));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21118#discussion_r1773603333

From liach at openjdk.org  Tue Sep 24 15:39:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 15:39:39 GMT
Subject: RFR: 8340708: Optimize StackMapGenerator::processMethod [v3]
In-Reply-To: <s8gigRBCeXaP9w6E46q5fe9cYwSZ64rpffNYlGlOfA0=.3770cbfb-609c-4dae-97b5-bfe4bdd39836@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
 <s8gigRBCeXaP9w6E46q5fe9cYwSZ64rpffNYlGlOfA0=.3770cbfb-609c-4dae-97b5-bfe4bdd39836@github.com>
Message-ID: <DUnpNvWIwTDDdB-IH1e2KvfhTB-l-M7Q2aEUd73XKSo=.8d0f882f-25b0-4489-af65-f6169019cb2c@github.com>

On Tue, 24 Sep 2024 05:04:19 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 283
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce getFrame

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21137#pullrequestreview-2325678251

From liach at openjdk.org  Tue Sep 24 16:01:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 16:01:54 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v8]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <xX-uCgvRwoRVQ726JBfPqM6KWnXExoTsBGAx0koaf-g=.c84c830c-b69c-4741-aa1d-223522691fa1@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Move raw opcodes to impl only
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - omission in tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Rename constants at new locations, link to related factories, cp tag constant names
 - Fix compile errors
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - ... and 7 more: https://git.openjdk.org/jdk/compare/212e3293...48082c76

-------------

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=07
  Stats: 2446 lines in 37 files changed: 537 ins; 908 del; 1001 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

PR: https://git.openjdk.org/jdk/pull/20773

From swen at openjdk.org  Tue Sep 24 16:04:52 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 16:04:52 GMT
Subject: RFR: 8340710: Optimize DirectClassBuilder::build [v2]
In-Reply-To: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
Message-ID: <pr9Ep9673eZbwfkdewmQYXZBuw1NfX2Lzv21TC7s6b0=.70e58d25-43c9-4e30-9d48-770557315be3@github.com>

> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
> 
> 1. DirectClassBuilder::build codeSize 361 -> 319
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
> 4. BufWriterImpl::writeU2 (forceinline)
> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
> 6. Util::writeList codSize 47 -> 42 (forceinline)

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_classfile_build_202409
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
 - suggestion from @liach
 - inline writeLong & local constantPool
 - fix write header
 - suggestion from @liach
 - force inline Util::writeAttributes & Util::writeList
 - force inline writeU2
 - force inline invalidIndex
 - optimize for writeExceptionHandlers for C1
 - optimize DirectClassBuilder::build

-------------

Changes: https://git.openjdk.org/jdk/pull/21118/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21118&range=01
  Stats: 50 lines in 4 files changed: 31 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21118.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21118/head:pull/21118

PR: https://git.openjdk.org/jdk/pull/21118

From liach at openjdk.org  Tue Sep 24 16:24:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 16:24:39 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v2]
In-Reply-To: <VPL9VbC9YOyV9-kvEihi_V6CVHSFCVxLIKHIHPu_rhI=.4a1132e1-7760-4dad-b072-f771300cd07e@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <VPL9VbC9YOyV9-kvEihi_V6CVHSFCVxLIKHIHPu_rhI=.4a1132e1-7760-4dad-b072-f771300cd07e@github.com>
Message-ID: <qRaIV_LZIRZMqpYJy-SFopjm4QwQWOIvz9CeO_Mr9Ow=.f24e969b-332c-4961-bfe6-8c3ca1437333@github.com>

On Sat, 21 Sep 2024 00:39:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - optimize Utf8EntryImpl inflate
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Suggestions from @liach
>  - fix build error
>  - optimize Utf8EntryImpl inflate

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 244:

> 242:         }
> 243: 
> 244:         private void inflateCHAR(int singleBytes, int hash) {

Can you rename this method to `inflateNonAscii`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20767#discussion_r1773670728

From liach at openjdk.org  Tue Sep 24 16:46:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 16:46:40 GMT
Subject: RFR: 8339358: Optimize TypeKind#from
In-Reply-To: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
Message-ID: <d-NthNfAkCcOSe4PkbWeNmbKEOgKbHTSM15ZbgPyHxA=.b2fb774d-377b-4ae4-a91d-5f7ebab7e003@github.com>

On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.
> 
> The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.
> 
> * baseline
> 
> @ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
>   @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>   @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
>   @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large
> 
> 
> * current
> 
> @ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large

Unfortunately, I don't think this is a good API addition, as it significantly increases the complexity of this method. If we do want to be performant, we should avoid calling this `from`, as in many workloads we don't handle `void` and we just want to return the 5 computational types for the class file format. We optimize users instead of this API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20762#issuecomment-2371808766

From rafael.wth at gmail.com  Tue Sep 24 16:47:33 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 24 Sep 2024 18:47:33 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <1df40152-d011-4629-a5b3-aeed667d9761@oracle.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
 <1df40152-d011-4629-a5b3-aeed667d9761@oracle.com>
Message-ID: <CA+DM0AkVn0b=q=D=3+mKF+F6cNO4UHY-FvdC55wsKv1p85kcYQ@mail.gmail.com>

Byte Buddy attempts to avoid class loading during build instrumentation, as
this might have side-effects when types are loaded, and described, using
the reflection API. Therefore Byte Buddy parses class files itself and
offers its own representation. 99.9% of users will be able to provide all
relevant class files by pointing to a jar file or a folder with classes,
and Byte Buddy will treat this as a form of class path to describe the
dependency tree to the build time instrumentation, without loading any
classes. As an option for the reminding 0.1%, dependencies can also be
provided using a ClassLoader. A case I have encountered more than once is
that a custom ClassLoader generates classes on demand if queried. To
support this, Byte Buddy then queries the ClassLoader for ".class" files
also, without processing a jar file or folder directly.

As of today, I have no way to tell the class loader that the target version
of the build plugin is for example Java 17, and that I want the Java 17
version of a class file. I can query for META-INF/versions 8-17 to see if
there is a class file for that name (rather inefficient). But if the build
is run on a Java 21 JVM and there is a META-INF/versions/21 version of a
class, the Java 17 "original" class file is not available to me. This is
why I was wondering if there should be a method to query a resource "as if"
it was requested for a particular version that is not the current JVM (or
JarFile-constructor-supplied) version.

Does this describe my problem better? I understand that this really is an
edge case. Then again I think this is a legitimate problem that should be
solvable. And with a shift towards build-time instrumentation and likely
growing adoption of MR JAR files, I would of course want to solve this in
Byte Buddy, if given the opportunity.

Am Di., 24. Sept. 2024 um 15:23 Uhr schrieb Alan Bateman <
alan.bateman at oracle.com>:

> On 24/09/2024 11:43, Rafael Winterhalter wrote:
> >
> > Without getting lost in specifics:
> >
> > Byte Buddy allows to transform classes and to store the transformed
> > state. Increasingly, this is done at build time to reduce start up
> > costs and to support AOT compilation. Java agents are the more common
> > option still, but I notice a shift to build time instrumentation, also
> > because of dynamic attach becoming less accessible. One consequence is
> > that the building JVM might not be of the same version as the
> > executing JVM.
> >
> > With this in mind, class files are read from either:
> > - A folder
> > - A JAR file
> > - A ClassLoader (getResourceAsStream)
> >
> > In build tools, the last option is rather uncommon, but it exists. I
> > can only assume that the people that requested this use case have good
> > enough reasons for this (probably because URLs are remote and the
> > logic to fetch them is wired into a loader implementation, I am
> > guessing, though).
> >
> > If the build plugin now wants to create instrumented versions of class
> > files for a Java 17 JVM, while the build is run on a Java 21 JVM, I
> > can support this for JAR files, for folders, but I cannot fetch the
> > adequate resource when the underlying resource accessor is a class
> > loader. I do not think that I can work around this, or do I overlook
> > something?
> >
>
> Tooling that does static instrumentation leads itself to a --release N
> option. Assuming this isn't a training runs of sorts it's hard hard to
> picture a ClassLoader in that environment. How does the build tool now
> what to setup so that it matches the arrangement and visibility of
> runtime? Is it really a ClassLoader or something just locates the class
> bytes in the same way as a ClassLoader at runtime?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/c1af1778/attachment.htm>

From henryjen at openjdk.org  Tue Sep 24 17:01:54 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 24 Sep 2024 17:01:54 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

-------------

Changes: https://git.openjdk.org/jdk/pull/21141/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=02
  Stats: 275 lines in 4 files changed: 274 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

PR: https://git.openjdk.org/jdk/pull/21141

From liach at openjdk.org  Tue Sep 24 17:23:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 17:23:41 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  AbstractPoolEntry is broken too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20773/files
  - new: https://git.openjdk.org/jdk/pull/20773/files/48082c76..1895449b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=07-08

  Stats: 12 lines in 1 file changed: 5 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

PR: https://git.openjdk.org/jdk/pull/20773

From alan.bateman at oracle.com  Tue Sep 24 18:11:48 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Sep 2024 19:11:48 +0100
Subject: ClassLoader API to look up class files
In-Reply-To: <CA+DM0AkVn0b=q=D=3+mKF+F6cNO4UHY-FvdC55wsKv1p85kcYQ@mail.gmail.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
 <1df40152-d011-4629-a5b3-aeed667d9761@oracle.com>
 <CA+DM0AkVn0b=q=D=3+mKF+F6cNO4UHY-FvdC55wsKv1p85kcYQ@mail.gmail.com>
Message-ID: <7f1294fb-0191-4b4a-8e2e-2307bb589c55@oracle.com>



On 24/09/2024 17:47, Rafael Winterhalter wrote:
> Byte Buddy attempts to avoid class loading during build 
> instrumentation, as this might have side-effects when types are 
> loaded, and described, using the reflection API. Therefore Byte Buddy 
> parses class files itself and offers its own representation. 99.9% of 
> users will be able to provide all relevant class files by pointing to 
> a jar file or a folder with classes, and Byte Buddy will treat this as 
> a form of class path to describe the dependency tree to the build time 
> instrumentation, without loading any classes. As an option for the 
> reminding 0.1%, dependencies can also be provided using a ClassLoader. 
> A case I have encountered more than once is that a custom ClassLoader 
> generates classes on demand if queried. To support this, Byte Buddy 
> then queries the ClassLoader for ".class" files also, without 
> processing a jar file or folder directly.
>
> As of today, I have no way to tell the class loader that the target 
> version of the build plugin is for example Java 17, and that I want 
> the Java 17 version of a class file. I can query for META-INF/versions 
> 8-17 to see if there is a class file for that name (rather 
> inefficient). But if the build is run on a Java 21 JVM and there is a 
> META-INF/versions/21 version of a class, the Java 17 "original" class 
> file is not available to me. This is why I was wondering if there 
> should be a method to query a resource "as if" it was requested for a 
> particular version that is not the current JVM (or 
> JarFile-constructor-supplied) version.
>
> Does this describe my problem better? I understand that this really is 
> an edge case. Then again I think this is a legitimate problem that 
> should be solvable. And with a shift towards build-time 
> instrumentation and likely growing adoption of MR JAR files, I would 
> of course want to solve this in Byte Buddy, if given the opportunity.
>
Thanks, I think the scenario is a much clearer now but I don't think 
adding a method to ClassLoader to aid this scenario is the right thing 
to do.

Instead, this feels like a ClassLoader implementation that is created 
with a Runtime.Version and excels at serving up resources. That's 
effectively what you get with using JDK tools like jdeps with the 
--multi-release N option. That ClassLoader implementation would create 
JarFiles with the Runtime.Version so it will locate the resources in MR 
JARs for that version. If you had such a ClassLoader implementation, 
could you fit into the build steps?

-Alan

From swen at openjdk.org  Tue Sep 24 18:41:41 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 24 Sep 2024 18:41:41 GMT
Subject: Withdrawn: 8339358: Optimize TypeKind#from
In-Reply-To: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
References: <JW6TQ1r1fL8NfhWZEI6O_HhqKwUMmmE7F7xa_J4MMw0=.e68ccac8-8133-4f62-99a1-5eda6ecf8e6f@github.com>
Message-ID: <poHDEu48tMeGerdM7IMgMe4wnFxJruYdZ48bvzleSQY=.bdb4ef2d-d033-4bbb-a436-01d169c26ba0@github.com>

On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance.
> 
> The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance degradation caused by cache misses.
> 
> * baseline
> 
> @ 48   java.lang.classfile.TypeKind::from (25 bytes)   inline
>   @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>   @ 10   java.lang.Class::descriptorString (170 bytes)   failed to inline: callee is too large
>   @ 15   java.lang.classfile.TypeKind::fromDescriptor (232 bytes)   failed to inline: callee is too large
> 
> 
> * current
> 
> @ 52   java.lang.classfile.TypeKind::from (103 bytes)   failed to inline: callee is too large

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20762

From lancea at openjdk.org  Tue Sep 24 19:24:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Sep 2024 19:24:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
Message-ID: <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>

On Tue, 24 Sep 2024 17:01:54 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

Thank you for tackling Henry.

A few initial comments.  Also please make sure to update the copyright on the files being updated to 2024

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 169:

> 167:         extracted: {0}
> 168: out.kept=\
> 169:         \ \ skipped: {0}

We might want to add a bit more wording to indicate it is being skipped due to the file already existing on disk

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 316:

> 314: main.help.opt.extract.keep-old-files=\
> 315: \  -k, --keep-old-files       Do not overwrite existing files.\n\
> 316: \                             In particular, if a file appears more than once in an\n\

In addition, we need to update the help to clarify -x. --extract behavior that it will overwrite by default.

Here is the verbiage from tar to give you a start

` -x      Extract to disk from the archive.  If a file with the same name appears more than
             once in the archive, each copy will be extracted, with later copies overwriting
             (replacing) earlier copies.  The long option form is --extract.`

test/jdk/tools/jar/ExtractFilesTest.java line 32:

> 30:  * @build jdk.test.lib.Platform
> 31:  *        jdk.test.lib.util.FileUtils
> 32:  * @run testng ExtractFilesTest

Please convert the test to use junit as we are moving away from testng

test/jdk/tools/jar/ExtractFilesTest.java line 94:

> 92: 
> 93:     @Test
> 94:     public void testExtract() throws IOException {

Please consider adding comments introducing the methods used by the test

-------------

PR Review: https://git.openjdk.org/jdk/pull/21141#pullrequestreview-2326184792
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773915982
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773915040
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773928582
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1773920945

From duke at openjdk.org  Tue Sep 24 19:40:23 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 24 Sep 2024 19:40:23 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v5]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <CQn44RKnE1S02t4a_sV0iSOnNdNR6CuYMLxGSqoZCk8=.582f2d06-2e9d-4877-85c8-62c43bf7f13c@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Test fixes and finish renaming

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/bf658a39..34d45238

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=03-04

  Stats: 31 lines in 5 files changed: 0 ins; 17 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From lancea at openjdk.org  Tue Sep 24 19:41:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Sep 2024 19:41:35 GMT
Subject: RFR: 8340684: Reading from an input stream backed by a closed
 ZipFile has no test coverage
In-Reply-To: <V_9qh9hA7lJHKD0-gFN-JObc8r3hs0ouVyATrcvmDdc=.a40afcd7-6b44-4667-b8ca-a193cd15bdeb@github.com>
References: <V_9qh9hA7lJHKD0-gFN-JObc8r3hs0ouVyATrcvmDdc=.a40afcd7-6b44-4667-b8ca-a193cd15bdeb@github.com>
Message-ID: <57IqkEAPIgEJrGWNXDHgZkQSIJZmA_KbrM5Vybk9Y_I=.91cd95a6-73ba-43cc-aed3-f60d4a42ddf1@github.com>

On Mon, 23 Sep 2024 18:05:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds test coverage for the case of reading from an input stream obtained using`ZipFile:getInputStream` after the backing `ZipFile` has been closed. 
> 
> The unspecified but long-standing behavior for this unusual use case is to throw `IOException`, but this is not verified by current tests. Adding a test would help prevent regressions in this area.
> 
> The test is parameterized to excercise a variation of stored/deflated entries, and a variation of read behaviors before the `ZipFile` is closed.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21142#pullrequestreview-2326279159

From lancea at openjdk.org  Tue Sep 24 19:48:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Sep 2024 19:48:35 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <vUS4NOiRJSQ3mf_iXxXRnCKQDvdMtPSxIQXw81d_JLM=.236c3d92-50d2-4b93-a3ab-cd230825ef54@github.com>

On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

Hi Eirik,

Given the changes proposed by Claes in this same area, I think we need to hold off until we can finalize the review of his proposed PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20905#issuecomment-2372234543

From psandoz at openjdk.org  Tue Sep 24 20:08:44 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 24 Sep 2024 20:08:44 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v17]
In-Reply-To: <-L7RYBQd-Q6zLkv5GKU0PDM2SZ-jdm1zAk1VRedDgyM=.c712848d-145b-4ecd-af2f-1a811832559d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <-L7RYBQd-Q6zLkv5GKU0PDM2SZ-jdm1zAk1VRedDgyM=.c712848d-145b-4ecd-af2f-1a811832559d@github.com>
Message-ID: <z7xtyOG56GSG7w2v_tKfJEFEeZzIgWWPPvy-K7EvPzk=.2c3b2191-f593-41ba-bd30-81b1e2b12c4b@github.com>

On Thu, 19 Sep 2024 06:53:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tuning extra spaces.

I sent a pull request to your branch https://github.com/jatin-bhateja/jdk/pull/5/files that moves the `VectorMath` test to the library area and updates it to be more like a library test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2372268735

From liach at openjdk.org  Tue Sep 24 20:26:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 20:26:44 GMT
Subject: RFR: 8340838: Clean up MutableCallSite to use explicit release fence
 instead of AtomicInteger
Message-ID: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>

This implementation code was written in JDK 7, before storeFence was available in JDK 8. We should update this legacy code to make it clear.

-------------

Commit messages:
 - 8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger

Changes: https://git.openjdk.org/jdk/pull/21169/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21169&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340838
  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21169/head:pull/21169

PR: https://git.openjdk.org/jdk/pull/21169

From rriggs at openjdk.org  Tue Sep 24 20:41:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Sep 2024 20:41:40 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v5]
In-Reply-To: <CQn44RKnE1S02t4a_sV0iSOnNdNR6CuYMLxGSqoZCk8=.582f2d06-2e9d-4877-85c8-62c43bf7f13c@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <CQn44RKnE1S02t4a_sV0iSOnNdNR6CuYMLxGSqoZCk8=.582f2d06-2e9d-4877-85c8-62c43bf7f13c@github.com>
Message-ID: <1k28oXqsXuBGzYOHpbE38LXpfnbB1-LLXJhZcKE5yg8=.e3c0729c-4214-4ec1-8fa2-ba2652a08dc3@github.com>

On Tue, 24 Sep 2024 19:40:23 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fixes and finish renaming

The updated comments help explain better what's being implemented.

src/java.base/share/classes/java/io/ObjectStreamReflection.java line 75:

> 73:      * @param ois the object stream (must not be {@code null})
> 74:      * @throws IOException if the call to {@link ObjectInputStream#readFields} or one of its field accessors throws this exception type
> 75:      * @throws ClassNotFoundException if the call to {@link ObjectInputStream#readFields} or one of its field accessors throws this exception type

Please wrap lines longer than 100-120 chars.

src/java.base/share/classes/java/io/ObjectStreamReflection.java line 171:

> 169:             }
> 170:             return streamClass;
> 171:         }

Possibly move common setup into the helper function:

Suggestion:

        public MethodHandle defaultReadObject(Class<?> clazz) {
            return handleForClass(DRO_HANDLE, clazz, ObjectInputStream.class);
        }

        public MethodHandle defaultWriteObject(Class<?> clazz) {
            return handleForClass(DWO_HANDLE, clazz, ObjectOutputStream.class);
        }

        private static MethodHandle handleForClass(MethodHandle handle, final Class<?> clazz, Class<?> ioClass) {
            ObjectStreamClass streamClass = ObjectStreamClass.lookup(clazz);
            if (streamClass != null) {
                try {
                    streamClass.checkDefaultSerialize();
                    return handle.bindTo(streamClass)
                            .asType(MethodType.methodType(void.class, clazz, ioClass));
                } catch (InvalidClassException e) {
                    // ignore and return null
                }
            }
            return null;
        }

-------------

PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2322681630
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1774053044
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1774061651

From rriggs at openjdk.org  Tue Sep 24 20:41:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Sep 2024 20:41:41 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v4]
In-Reply-To: <WGDHTMUur7b-GAJdSpstgSs-QwRGXGB1RwpHSP0JCS0=.41402e2d-9e9b-49a2-a181-37a40be97458@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <WGDHTMUur7b-GAJdSpstgSs-QwRGXGB1RwpHSP0JCS0=.41402e2d-9e9b-49a2-a181-37a40be97458@github.com>
Message-ID: <HWc75XXwET0vRpszzzdwackUYVpKD6ahXVER-qj04Yg=.44cd2128-5e1a-4a4c-938c-b2e48337f6ec@github.com>

On Fri, 20 Sep 2024 22:01:23 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

src/java.base/share/classes/java/io/ObjectStreamReflection.java line 98:

> 96:         }
> 97:         streamClass.setPrimFieldValues(obj, bytes);
> 98:         streamClass.checkObjFieldValueTypes(obj, objs);

Please move to before setting the primitive fields. If an exception occurs, none of the field accesses should have been done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1771696354

From jrose at openjdk.org  Tue Sep 24 21:11:34 2024
From: jrose at openjdk.org (John R Rose)
Date: Tue, 24 Sep 2024 21:11:34 GMT
Subject: RFR: 8340838: Clean up MutableCallSite to use explicit release
 fence instead of AtomicInteger
In-Reply-To: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
References: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
Message-ID: <G33q7SGNSxOTQCb5hkqhnliF8EyMdbYInBqpF-arn1c=.4702d86c-7112-4af2-803a-1f3f51e202cb@github.com>

On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> This implementation code was written in JDK 7, before storeFence was available in JDK 8. We should update this legacy code to make it clear.

Good, thank you.  Nice to see that silly variable go away.

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21169#pullrequestreview-2326485048

From redestad at openjdk.org  Tue Sep 24 21:19:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 24 Sep 2024 21:19:35 GMT
Subject: RFR: 8340838: Clean up MutableCallSite to use explicit release
 fence instead of AtomicInteger
In-Reply-To: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
References: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
Message-ID: <JbSVT5NhMyet73-zx9cSeEgMdTgw7Wwko0sbxT-oxGI=.54faadde-365f-41a4-a1c5-010eaf532abc@github.com>

On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> This implementation code was written in JDK 7, before storeFence was available in JDK 8. We should update this legacy code to make it clear.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21169#pullrequestreview-2326497113

From ccheung at openjdk.org  Tue Sep 24 21:20:16 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 24 Sep 2024 21:20:16 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/61ffd1b2..661615cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From ccheung at openjdk.org  Tue Sep 24 21:20:16 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 24 Sep 2024 21:20:16 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <p_rRUuAYIri6ve8E-FKQzeqVQG2LRa5LL368xHYvcBc=.905f0ce3-a95b-43b8-bbae-2f812004c38b@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
 <p_rRUuAYIri6ve8E-FKQzeqVQG2LRa5LL368xHYvcBc=.905f0ce3-a95b-43b8-bbae-2f812004c38b@github.com>
Message-ID: <B9_yEeuGFbptYX51_EhJKjMMPylpB4_qUdZjCFrQQhA=.67cb1008-7c64-4704-bab0-1f10c3ab558e@github.com>

On Tue, 24 Sep 2024 05:06:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trailing whitespace
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 481:
> 
>> 479:                     cf,
>> 480:                     clf,
>> 481:                     mainModule);
> 
> This was correctly aligned before, now it isn't.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774104849

From duke at openjdk.org  Tue Sep 24 21:36:37 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 24 Sep 2024 21:36:37 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v5]
In-Reply-To: <CQn44RKnE1S02t4a_sV0iSOnNdNR6CuYMLxGSqoZCk8=.582f2d06-2e9d-4877-85c8-62c43bf7f13c@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <CQn44RKnE1S02t4a_sV0iSOnNdNR6CuYMLxGSqoZCk8=.582f2d06-2e9d-4877-85c8-62c43bf7f13c@github.com>
Message-ID: <V8MHL1Ng5PB_UHXgx7ae4XW50tL4GW7lTkZ642o9Gu4=.3259c84c-ce90-49a3-b3ab-d9bfdcc7de19@github.com>

On Tue, 24 Sep 2024 19:40:23 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fixes and finish renaming

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 81:

> 79:         this.langReflectAccess = SharedSecrets.getJavaLangReflectAccess();
> 80:         this.javaObjectStreamDefaultSupportAccess = SharedSecrets.getJavaObjectStreamReflectionAccess();
> 81:     }

Suggestion:

    private final JavaObjectStreamReflectionAccess javaObjectStreamReflectionAccess;
    private ReflectionFactory() {
        this.langReflectAccess = SharedSecrets.getJavaLangReflectAccess();
        this.javaObjectStreamReflectionAccess = SharedSecrets.getJavaObjectStreamReflectionAccess();
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1774119697

From liach at openjdk.org  Tue Sep 24 22:13:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Sep 2024 22:13:02 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
Message-ID: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>

`MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.

-------------

Commit messages:
 - 8340831: Simplify simple validation for class definition in MethodHandles.Lookup

Changes: https://git.openjdk.org/jdk/pull/21170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340831
  Stats: 136 lines in 2 files changed: 19 ins; 58 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/21170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21170/head:pull/21170

PR: https://git.openjdk.org/jdk/pull/21170

From iklam at openjdk.org  Wed Sep 25 00:40:43 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 25 Sep 2024 00:40:43 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
Message-ID: <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>

On Tue, 24 Sep 2024 21:20:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

src/hotspot/share/cds/filemap.cpp line 956:

> 954:   }
> 955:   // module paths are stored in sorted order in the CDS archive.
> 956:   module_paths->sort(ClassLoaderExt::compare_module_path_by_name);

I think it's better to put this call inside `ClassLoaderExt::extract_jar_files_from_path`

src/hotspot/share/cds/heapShared.cpp line 879:

> 877: 
> 878:   ResourceMark rm(THREAD);
> 879:   if ((strcmp(k->name()->as_C_string(), "jdk/internal/module/ArchivedModuleGraph") == 0) &&

You can avoid the ResourceMark by


if (k->name()->equals("jdk/internal/module/ArchivedModuleGraph")

src/hotspot/share/cds/heapShared.cpp line 885:

> 883:     log_info(cds, heap)("Skip initializing ArchivedModuleGraph subgraph: is_using_optimized_module_handling=%s num_module_paths=%d",
> 884:                         BOOL_TO_STR(CDSConfig::is_using_optimized_module_handling()), ClassLoaderExt::num_module_paths());
> 885:     return;

I think we can add a comment like:


ArchivedModuleGraph was created with a --module-path that's different than the runtime --module-path.
Thus, it might contain references to modules that do not exist in runtime. We cannot use it.

src/hotspot/share/classfile/classLoader.cpp line 582:

> 580:                                       false /*is_boot_append */, false /* from_class_path_attr */);
> 581:   if (new_entry != nullptr) {
> 582:     assert(new_entry->is_jar_file(), "module path entry %s is not a jar file", new_entry->name());

How do we guarantee that new_entry is never a JAR file? Do we never come here if --module-path points to an exploded directory? A comment would be helpful.

src/hotspot/share/classfile/classLoaderExt.cpp line 152:

> 150:   DIR* dirp = os::opendir(path);
> 151:   if (dirp == nullptr && errno == ENOTDIR && has_jar_suffix(path)) {
> 152:     module_paths->append(path);

Does this handle the case where `path` doesn't exist?

src/hotspot/share/classfile/classLoaderExt.cpp line 162:

> 160:         int n = os::snprintf(full_name, full_name_len, "%s%s%s", path, os::file_separator(), file_name);
> 161:         assert((size_t)n == full_name_len - 1, "Unexpected number of characters in string");
> 162:         module_paths->append(full_name);

Can this case be handled: --module-path=dir

- Dump time :  dir contains only mod1.jar
- Run time :  dir contains only mod1.jar and mod2.jmod

src/hotspot/share/runtime/arguments.cpp line 347:

> 345:     }
> 346:   }
> 347:   return false;

Can this be simplified to `return (strcmp(key, MODULE_PROPERTY_PREFIX PATH) == 0)`?

src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 1092:

> 1090:     void resetArchivedStatesForAppClassLoader() {
> 1091:         setClassPath(null);
> 1092:         if (!moduleToReader.isEmpty()) moduleToReader.clear();

Suggestion:

        if (!moduleToReader.isEmpty()) {
            moduleToReader.clear();
        }


Also, do we need to do the same thing for the platform loader as well?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774242056
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774243535
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774245579
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774247339
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774248778
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774249819
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774251713
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1774252333

From swen at openjdk.org  Wed Sep 25 01:10:04 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 25 Sep 2024 01:10:04 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v3]
In-Reply-To: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
Message-ID: <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>

> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - inflateNonAscii
 - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - optimize Utf8EntryImpl inflate
 - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - Suggestions from @liach
 - fix build error
 - optimize Utf8EntryImpl inflate

-------------

Changes: https://git.openjdk.org/jdk/pull/20767/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20767&range=02
  Stats: 75 lines in 1 file changed: 22 ins; 19 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/20767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20767/head:pull/20767

PR: https://git.openjdk.org/jdk/pull/20767

From liach at openjdk.org  Wed Sep 25 01:17:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 01:17:36 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v3]
In-Reply-To: <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
Message-ID: <3MgyoOv0BvSZMwzKt1O-ycbTeIY29-leSUk2mLRr3yo=.9d4814e6-3112-48f0-a3cd-37cc3c87f0f8@github.com>

On Wed, 25 Sep 2024 01:10:04 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - inflateNonAscii
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - optimize Utf8EntryImpl inflate
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Suggestions from @liach
>  - fix build error
>  - optimize Utf8EntryImpl inflate

Thanks for this rename and cleanup. Is `inflateNonAscii` code size less than 325?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20767#issuecomment-2372672463

From liach at openjdk.org  Wed Sep 25 01:24:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 01:24:26 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v3]
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: <uoLOjyJO8jlzzNXSmC8X09TqQsRwewwRhu6IfHMsiSc=.5f3f52b7-76d9-44b3-80f9-4aa86e52cb70@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 pull request now contains 18 commits:

 - Post-merge cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Remove redundant try-catch in getEnclosingMethod/Constructor
 - Merge branch 'test/signature-error' into feature/new-generic-info
 - Fix everything
 - Fixxes
 - Stage
 - Stage new tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - ... and 8 more: https://git.openjdk.org/jdk/compare/0b8c9f6d...86b89e5b

-------------

Changes: https://git.openjdk.org/jdk/pull/19281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=02
  Stats: 4609 lines in 66 files changed: 1027 ins; 3487 del; 95 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 jpai at openjdk.org  Wed Sep 25 01:47:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Sep 2024 01:47:38 GMT
Subject: RFR: 8340717: Remove unused function declarations from
 java.c/java.h of the launcher
In-Reply-To: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
References: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
Message-ID: <JnUEKiaiz4gAZ9cu0gLu94GMpwsjWQD5U8hce1yv7KM=.bb7aea0b-6568-4b61-9625-ad20f87ab27f@github.com>

On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?
> 
> The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8194937.
> 
> The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).
> 
> The data model related macros, being removed in this PR, are unused and no longer relevant.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21149#issuecomment-2372712078

From jpai at openjdk.org  Wed Sep 25 01:47:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Sep 2024 01:47:38 GMT
Subject: Integrated: 8340717: Remove unused function declarations from
 java.c/java.h of the launcher
In-Reply-To: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
References: <tNHMLLAUnqf8ll5tqFELpIOzJ5xfMHTQ3iQDDOAQbW8=.9a47e0c1-70ad-4004-93bd-c27e8dc23d50@github.com>
Message-ID: <ZknYsZOT5AcDC-VKPxrOsqjAngMI8TvOuWoTF1NToBo=.b5b5ebde-bb9f-4754-8160-1023ad1debf0@github.com>

On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup to the launcher code to remove declarations of unused functions?
> 
> The `ValidateModules` function appears to be a left-over from https://bugs.openjdk.org/browse/JDK-8194937.
> 
> The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have been unused for a long time (ever since the first commit in the current JDK repo).
> 
> The data model related macros, being removed in this PR, are unused and no longer relevant.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

This pull request has now been integrated.

Changeset: c0fcb258
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0fcb258bbd02892267970dc4bc082dc7761f074
Stats:     12 lines in 2 files changed: 0 ins; 12 del; 0 mod

8340717: Remove unused function declarations from java.c/java.h of the launcher

Reviewed-by: alanb, dholmes, shade, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/21149

From swen at openjdk.org  Wed Sep 25 02:33:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 25 Sep 2024 02:33:43 GMT
Subject: Integrated: 8340708: Optimize StackMapGenerator::processMethod
In-Reply-To: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
References: <QD-uhUWVCP_YLUbY3987FtdEk0WFHD76DJsWF0zYf7Y=.e40663e0-d4d9-4972-a40e-25cbbfe2e410@github.com>
Message-ID: <97encJpXrzJXN4VjjWAbzKQYOgKOLrD-j3fpCUVTYuI=.3bfce44d-1b8d-4da1-a4ca-40f10ff23aff@github.com>

On Mon, 23 Sep 2024 13:53:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization of processMethod, by using local variables and extracting exception methods, reduces codeSize from 326 to 283

This pull request has now been integrated.

Changeset: 9bcc7b66
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bcc7b66de6495d3da8fc7f30a2a88187dbe847d
Stats:     6 lines in 1 file changed: 3 ins; 1 del; 2 mod

8340708: Optimize StackMapGenerator::processMethod

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21137

From swen at openjdk.org  Wed Sep 25 02:35:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 25 Sep 2024 02:35:43 GMT
Subject: Integrated: 8340587: Optimize
 StackMapGenerator$Frame::checkAssignableTo
In-Reply-To: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
References: <cq0Cb2nlWuQpnCLOW9VhFpdRzt3DpImv8_St8_Z-PlQ=.6f074aa3-e409-4ee9-92d5-493046b1ac66@github.com>
Message-ID: <XkkrSZ3qb2ShGGfH2VIGgVFT1dHPT-8KpQg1Br794xI=.3cbb5984-98a9-496a-bd63-493eec341072@github.com>

On Sun, 22 Sep 2024 13:20:01 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone instead of Array.copyOf to avoid compression and then expansion

This pull request has now been integrated.

Changeset: 2d38af61
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d38af61e4133ca98d5a98b3cfb6a6dde2877026
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8340587: Optimize StackMapGenerator$Frame::checkAssignableTo

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21121

From swen at openjdk.org  Wed Sep 25 02:38:41 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 25 Sep 2024 02:38:41 GMT
Subject: Integrated: 8340710: Optimize DirectClassBuilder::build
In-Reply-To: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
References: <b5Ap5h7gJk9aFti6yHHNarSCkDH-MTTKfB04rkzFUY4=.d45f9617-6e78-4c81-a6a2-13871dadc7d3@github.com>
Message-ID: <IMr3CmK41uyy29_40wEwiCpBbyDVlDDaUl2SjgrOZW0=.74595fef-169c-4b43-874e-85a529d041ca@github.com>

On Sun, 22 Sep 2024 05:30:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
> 
> 1. DirectClassBuilder::build codeSize 361 -> 319
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
> 4. BufWriterImpl::writeU2 (forceinline)
> 5. Util::writeAttributes codSize 45 -> 40 (forceinline)
> 6. Util::writeList codSize 47 -> 42 (forceinline)

This pull request has now been integrated.

Changeset: 2e0554a6
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e0554a69548dae6e8ce9eec48c82e08dd3c1ffa
Stats:     50 lines in 4 files changed: 31 ins; 4 del; 15 mod

8340710: Optimize DirectClassBuilder::build

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21118

From jbhateja at openjdk.org  Wed Sep 25 04:39:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Sep 2024 04:39:26 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v18]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <FbmN3EVQXnib365TFTuTVNW3zvsdzXu8yF_-PIuJm_o=.59dda984-b9f7-4977-9104-89ceaacf80eb@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #5 from PaulSandoz/JDK-8338201
   
   Move and convert test
 - Move and convert test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/eb2960a9..28b29bc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=16-17

  Stats: 523 lines in 2 files changed: 245 ins; 278 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From thartmann at openjdk.org  Wed Sep 25 06:30:50 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 06:30:50 GMT
Subject: RFR: 8340812: LambdaForm customization via MethodHandle::updateForm is
 not thread safe
Message-ID: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>

When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:

https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143

The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982

After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883

The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).

In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:

	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)

The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being reordered with the subsequent store to the `MethodHandle::form` field that would make it accessible by other threads.

I removed the `fullFence` which should not be needed. 

Unfortunately, my new tests seems to trigger another issue (even if I leave the `fullFence` in):

java.lang.AssertionError
	at java.base/java.lang.invoke.LambdaForm.arityCheck(LambdaForm.java:1006)
	at TestLambdaFormCustomization.lambda$test$0(TestLambdaFormCustomization.java:46)
	at java.base/java.lang.Thread.run(Thread.java:1576)


It's this assert:
https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L1010

UPDATE: After discussing with @JornVernee, it seems that my test using `-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=1` was the issue since that flag triggers some untested code paths. I removed that flag from the test, verified that it still triggers the original issue and leave it to the method handle maintainers to address this issue separately.

Thanks to @eme64 for taking a first step at simplifying the original test.

Best regards,
Tobias

-------------

Commit messages:
 - Use putReferenceRelease
 - Change from driver to main
 - Updated copyright year
 - Don't use COMPILE_THRESHOLD=1 in the test. Verified that it still reproduces
 - Removed fullFence
 - 8340812: LambdaForm customization via MethodHandle::updateForm is not thread safe

Changes: https://git.openjdk.org/jdk/pull/21160/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340812
  Stats: 73 lines in 2 files changed: 70 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21160/head:pull/21160

PR: https://git.openjdk.org/jdk/pull/21160

From liach at openjdk.org  Wed Sep 25 06:30:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 06:30:50 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <YhlZ2M_QziE_JMSPBNR-SFR4jNCc8S_fk3PiMOKyi_4=.50a73b38-92d8-4875-8d37-873699a36661@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Looks good; the form field is final so it should already have loadLoadFence at read. The full fence seems redundant, as the old and new forms must be functionally the same.

Marked as reviewed by liach (Reviewer).

For the test failure: LambdaForm goes from generic to specific; we prefer to compile lambda forms before customizing them (as you see, all our customization eagerly compiles the customized result). And seems the interpreter LF code doesn't expect customized forms.

Maybe we can add some checks to ensure the customization threshold is not less than the compilation threshold.

@TobiHartmann Do we need some test tags like "intermittent" for such a chance-based concurrency test?

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1:

> 1: /*

You can bump the year here if you'd like to.

test/jdk/java/lang/invoke/TestLambdaFormCustomization.java line 32:

> 30:   * @bug 8340812
> 31:   * @summary Verify that LambdaForm customization via MethodHandle::updateForm is thread safe.
> 32:   * @run driver TestLambdaFormCustomization

Looks a bit weird that you use `driver` here and `main` on the next line; what's the convention like?

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21160#pullrequestreview-2325572020
PR Review: https://git.openjdk.org/jdk/pull/21160#pullrequestreview-2325650013
PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2371583482
PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2371592225
PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1773566766
PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1773565669

From thartmann at openjdk.org  Wed Sep 25 06:30:50 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 06:30:50 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <YhlZ2M_QziE_JMSPBNR-SFR4jNCc8S_fk3PiMOKyi_4=.50a73b38-92d8-4875-8d37-873699a36661@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <YhlZ2M_QziE_JMSPBNR-SFR4jNCc8S_fk3PiMOKyi_4=.50a73b38-92d8-4875-8d37-873699a36661@github.com>
Message-ID: <vFCYAQ98rZyiJcY3yVdt2pgM5XvN4O9KlMQlDG8pbPY=.7cc8ee57-9551-4602-bdf9-acecdae0fea1@github.com>

On Tue, 24 Sep 2024 15:11:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
>> 
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
>> 
>> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
>> 
>> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
>> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
>> 
>> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
>> 
>> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
>> 
>> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
>> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
>> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
>> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
>> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
>> 
>> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent store...
>
> @TobiHartmann Do we need some test tags like "intermittent" for such a chance-based concurrency test?

Thanks for you review, @liach!

> And seems the interpreter LF code doesn't expect customized forms.

Right, I discussed with @JornVernee off-thread who mentioned the same. I removed that flag from the test, verified that it still triggers the original issue and leave it to the method handle maintainers to address this issue separately.

Running some more testing now.

> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1:
> 
>> 1: /*
> 
> You can bump the year here if you'd like to.

Thanks! Done.

> test/jdk/java/lang/invoke/TestLambdaFormCustomization.java line 32:
> 
>> 30:   * @bug 8340812
>> 31:   * @summary Verify that LambdaForm customization via MethodHandle::updateForm is thread safe.
>> 32:   * @run driver TestLambdaFormCustomization
> 
> Looks a bit weird that you use `driver` here and `main` on the next line; what's the convention like?

To specify custom arguments, I need to run with `othervm`, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2371605778
PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1773574621
PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1773575768

From thartmann at openjdk.org  Wed Sep 25 06:30:50 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 06:30:50 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <9tNOLBIOUia045g9pS7jgJgqty5E6OVxS1Tp8rNgODA=.2107120a-8c9d-4a07-97a9-703f529422b9@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Thanks again for the review. I'll open this once my testing passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2371646077

From shade at openjdk.org  Wed Sep 25 06:30:51 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Sep 2024 06:30:51 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <nopzYEyg_jmH9EO_LiW_LVSl8AzZ8Yle_eS--5Dx0SE=.dd5f63f8-de7b-4235-99e3-9c12537a094d@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1882:

> 1880:                     assert (newForm.customized == null || newForm.customized == this);
> 1881:                     newForm.prepare(); // as in MethodHandle.<init>
> 1882:                     UNSAFE.storeStoreFence(); // properly publish newForm

I agree `fullFence` was misplaced. Not sure if `storeStore` is sufficient here, if we exposed the old instance somehow. It is safer to use release. And I think an even cleaner way would be to drop the fence and call `Unsafe.putReferenceRelease` below, which solves this as well: it publishes new instance with release semantics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1773741732

From thartmann at openjdk.org  Wed Sep 25 06:30:51 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 06:30:51 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <nopzYEyg_jmH9EO_LiW_LVSl8AzZ8Yle_eS--5Dx0SE=.dd5f63f8-de7b-4235-99e3-9c12537a094d@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <nopzYEyg_jmH9EO_LiW_LVSl8AzZ8Yle_eS--5Dx0SE=.dd5f63f8-de7b-4235-99e3-9c12537a094d@github.com>
Message-ID: <6_qw1dll0ORscesOaPfDGeR979tKUhqKfmaRwvK5Lcc=.d5d8c703-00b1-43e9-9330-5292cf8001e0@github.com>

On Tue, 24 Sep 2024 17:15:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
>> 
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
>> 
>> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
>> 
>> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
>> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
>> 
>> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
>> 
>> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
>> 
>> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
>> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
>> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
>> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
>> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
>> 
>> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent store...
>
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1882:
> 
>> 1880:                     assert (newForm.customized == null || newForm.customized == this);
>> 1881:                     newForm.prepare(); // as in MethodHandle.<init>
>> 1882:                     UNSAFE.storeStoreFence(); // properly publish newForm
> 
> I agree `fullFence` was misplaced. Not sure if `storeStore` is sufficient here, if we exposed the old instance somehow. It is safer to use release. And I think an even cleaner way would be to drop the fence and call `Unsafe.putReferenceRelease` below, which solves this as well: it publishes new instance with release semantics.

Thanks Aleksey, makes sense. Let's use `putReferenceRelease` then. There are a few other, existing uses of `UNSAFE.storeStoreFence` in the libraries code, especially in similar places in `java/lang/invoke/`. Maybe these should be double checked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1774575296

From thartmann at openjdk.org  Wed Sep 25 06:30:51 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 06:30:51 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <vFCYAQ98rZyiJcY3yVdt2pgM5XvN4O9KlMQlDG8pbPY=.7cc8ee57-9551-4602-bdf9-acecdae0fea1@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <YhlZ2M_QziE_JMSPBNR-SFR4jNCc8S_fk3PiMOKyi_4=.50a73b38-92d8-4875-8d37-873699a36661@github.com>
 <vFCYAQ98rZyiJcY3yVdt2pgM5XvN4O9KlMQlDG8pbPY=.7cc8ee57-9551-4602-bdf9-acecdae0fea1@github.com>
Message-ID: <tHYQZEzWZoriC2HTmfmhJT24UIg38T3JhH2Uj4CIOQ8=.35a7f4ae-f2c5-4ea8-8591-c880137449ea@github.com>

On Tue, 24 Sep 2024 15:18:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/TestLambdaFormCustomization.java line 32:
>> 
>>> 30:   * @bug 8340812
>>> 31:   * @summary Verify that LambdaForm customization via MethodHandle::updateForm is thread safe.
>>> 32:   * @run driver TestLambdaFormCustomization
>> 
>> Looks a bit weird that you use `driver` here and `main` on the next line; what's the convention like?
>
> To specify custom arguments, I need to run with `othervm`, right?

Ah, but I can of course use `@run main` here as well. Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1773581694

From asotona at openjdk.org  Wed Sep 25 06:38:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 25 Sep 2024 06:38:35 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
Message-ID: <l_V9wPI1ZNiBHXu4OwuWxWZ276D3-4OhKqj_xcXot0U=.54a88058-b51f-413e-b2d1-bfffa8de4254@github.com>

On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AbstractPoolEntry is broken too

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20773#pullrequestreview-2327211669

From shade at openjdk.org  Wed Sep 25 09:20:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Sep 2024 09:20:37 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <CDohzd09aZD9zlFlnwEjXjWXxh-1Svewc6M2VcM6pAI=.dda208e3-0818-48aa-8e82-a28d0c8ba1ad@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21160#pullrequestreview-2327678641

From redestad at openjdk.org  Wed Sep 25 09:21:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 09:21:04 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison
Message-ID: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>

This PR desugars the enum added by JDK-8301873 to reduce classes loaded on bootstrap and stored in the default CDS archive by 2.

-------------

Commit messages:
 - Fix docs
 - Merge branch 'master' into no-comparison
 - Desugar Comparison enum

Changes: https://git.openjdk.org/jdk/pull/21176/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340885
  Stats: 25 lines in 2 files changed: 0 ins; 1 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21176/head:pull/21176

PR: https://git.openjdk.org/jdk/pull/21176

From eirbjo at openjdk.org  Wed Sep 25 09:57:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 09:57:35 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison
In-Reply-To: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
Message-ID: <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>

On Wed, 25 Sep 2024 09:15:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on bootstrap and stored in the default CDS archive by 2.

Looks good to me, some minor suggestions inline.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 59:

> 57: 
> 58:     /**
> 59:      * These values represents the three possible return values for

Consider simplifying to

Suggestion:

     * Constants representing the three possible return values for

src/java.base/share/classes/java/util/zip/ZipCoder.java line 69:

> 67:          * to the encoded string.
> 68:          */
> 69:         EXACT_MATCH = 1,

Would there be any (positive) performance implications of starting these at zero?

src/java.base/share/classes/java/util/zip/ZipFile.java line 1872:

> 1870:                     // Compare the lookup name with the name encoded in the CEN
> 1871:                     switch (zc.compare(name, cen, noff, nlen, addSlash)) {
> 1872:                         case ZipCoder.EXACT_MATCH:

This would perhaps read cleaner with a static import of the constants?

-------------

Marked as reviewed by eirbjo (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21176#pullrequestreview-2327763749
PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1774928268
PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1774929175
PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1774931076

From redestad at openjdk.org  Wed Sep 25 10:06:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 10:06:41 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
Message-ID: <el8WYcDa2xcKAmgVa08BLFsC94L0H0MKik0aH18AmEs=.3b6807c6-c6de-43ee-994a-98e71931a05e@github.com>

On Tue, 24 Sep 2024 22:07:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.

Changes requested by redestad (Reviewer).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2276:

> 2274:                 var thisClass = cm.thisClass();
> 2275:                 name = thisClass.asInternalName();
> 2276:                 sym = thisClass.asSymbol();

We only use this for determining package name are equal, and sym.packageName() does the similar transformations plus a bit more. Likely not a significant cost compared to the `ClassFile::parse` - but perhaps there's room for a utility method to get the package name directly from an internal name?

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2440:

> 2438:         }
> 2439: 
> 2440:         record ClassDefiner(Lookup lookup, String name, byte[] bytes, int classFlags, ClassFileDumper dumper) {

Rename `name` to `internalName`, dropping the explicit `internalName()` method.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21170#pullrequestreview-2327774125
PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1774943742
PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1774934606

From redestad at openjdk.org  Wed Sep 25 10:12:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 10:12:50 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
Message-ID: <Dl0z3-17QlfLp9lBOtrZ6Gg4f2kS1JjXXMZrfGCiE8U=.f05680aa-2dfd-4de2-94ec-fb10b7eab099@github.com>

> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on bootstrap and stored in the default CDS archive by 2.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Shift constant values
 - Update src/java.base/share/classes/java/util/zip/ZipCoder.java
   
   Co-authored-by: Eirik Bjorsnos <eirbjo at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21176/files
  - new: https://git.openjdk.org/jdk/pull/21176/files/9edd65e2..d8c06f07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21176&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21176&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21176/head:pull/21176

PR: https://git.openjdk.org/jdk/pull/21176

From redestad at openjdk.org  Wed Sep 25 10:12:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 10:12:50 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
 <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>
Message-ID: <7phE7PvLEhg1tNKTNXPZggppNibXuzGR8jVHTuIt1CU=.7cd3cdce-f72b-45ec-8a93-9ddc68fedb47@github.com>

On Wed, 25 Sep 2024 09:52:20 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Shift constant values
>>  - Update src/java.base/share/classes/java/util/zip/ZipCoder.java
>>    
>>    Co-authored-by: Eirik Bjorsnos <eirbjo at gmail.com>
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 69:
> 
>> 67:          * to the encoded string.
>> 68:          */
>> 69:         EXACT_MATCH = 1,
> 
> Would there be any (positive) performance implications of starting these at zero?

It saves a byte since there are bytecode constants for `0`-`2` but not for `3` :-) Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1774954413

From jvernee at openjdk.org  Wed Sep 25 10:15:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Sep 2024 10:15:36 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <Ps7RaILH2O6O6UL6T6wWwrwZvK_3DqdVPwrUisPL-z4=.9657e206-7209-4670-ba7e-ab38b29c0642@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21160#pullrequestreview-2327811911

From redestad at openjdk.org  Wed Sep 25 10:17:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 10:17:35 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
 <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>
Message-ID: <FSkGGjPA4DZJy09W4b1cEL1bgN-73U38AAALvBzJ3BU=.f2993162-88d3-4f23-abf6-d83d9c33f087@github.com>

On Wed, 25 Sep 2024 09:53:39 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Shift constant values
>>  - Update src/java.base/share/classes/java/util/zip/ZipCoder.java
>>    
>>    Co-authored-by: Eirik Bjorsnos <eirbjo at gmail.com>
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1872:
> 
>> 1870:                     // Compare the lookup name with the name encoded in the CEN
>> 1871:                     switch (zc.compare(name, cen, noff, nlen, addSlash)) {
>> 1872:                         case ZipCoder.EXACT_MATCH:
> 
> This would perhaps read cleaner with a static import of the constants?

No strong feeling about this, but I lean towards not using static imports unless there's repeated use.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1774960752

From eirbjo at openjdk.org  Wed Sep 25 10:22:36 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 10:22:36 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <FSkGGjPA4DZJy09W4b1cEL1bgN-73U38AAALvBzJ3BU=.f2993162-88d3-4f23-abf6-d83d9c33f087@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
 <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>
 <FSkGGjPA4DZJy09W4b1cEL1bgN-73U38AAALvBzJ3BU=.f2993162-88d3-4f23-abf6-d83d9c33f087@github.com>
Message-ID: <ptGfbz2FsW1zk2Xxf0xXSIc13gtSWFspnnb-nQUmjoY=.1d268200-b25a-4b87-bce1-714030eea1d8@github.com>

On Wed, 25 Sep 2024 10:14:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1872:
>> 
>>> 1870:                     // Compare the lookup name with the name encoded in the CEN
>>> 1871:                     switch (zc.compare(name, cen, noff, nlen, addSlash)) {
>>> 1872:                         case ZipCoder.EXACT_MATCH:
>> 
>> This would perhaps read cleaner with a static import of the constants?
>
> No strong feeling about this, but I lean towards not using static imports unless there's repeated use.

No strong feelings here either, just thought it made the code easier on the eye. I'll leave it to your preference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1774967673

From redestad at openjdk.org  Wed Sep 25 10:22:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 10:22:37 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <Pl0LZ2z6ksSC9t22Te_CgXhYX3f49Wkk7UdcWViSJfc=.707c0a54-308f-463c-b961-31604eb90a59@github.com>

On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

I'm ok with this going in first since it's the more trivial change. I hadn't paid attention to this change as I started pulling at the strings that led to #21133.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20905#issuecomment-2373669037

From redestad at openjdk.org  Wed Sep 25 10:49:39 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 10:49:39 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <7phE7PvLEhg1tNKTNXPZggppNibXuzGR8jVHTuIt1CU=.7cd3cdce-f72b-45ec-8a93-9ddc68fedb47@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
 <_YCORkBo8yajjiVFDLKkF_IqnW9dxJGwTuOxtC04b8w=.2c26eb40-356b-4a4d-9dee-603bf80f2301@github.com>
 <7phE7PvLEhg1tNKTNXPZggppNibXuzGR8jVHTuIt1CU=.7cd3cdce-f72b-45ec-8a93-9ddc68fedb47@github.com>
Message-ID: <gL-5zajPs3SCLqhiXC6fAbRFR2fOzcm_02HpYn5wUwQ=.6ec4b36f-8e46-42ec-ac74-82fe4a46ce0f@github.com>

On Wed, 25 Sep 2024 10:10:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipCoder.java line 69:
>> 
>>> 67:          * to the encoded string.
>>> 68:          */
>>> 69:         EXACT_MATCH = 1,
>> 
>> Would there be any (positive) performance implications of starting these at zero?
>
> It saves a byte since there are bytecode constants for `0`-`2` but not for `3` :-) Fixed

I misremembered: there are constant, single byte bytecodes up to `ICONST_5`. Alas, it's done, and no backsies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21176#discussion_r1775004504

From eirbjo at openjdk.org  Wed Sep 25 10:56:07 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 10:56:07 GMT
Subject: RFR: 8340887: Add micro benchmark comparing input stream performance
 of ZipFile vs ZipInputStream
Message-ID: <yrTkspfd60XRlM8J2fdlf55HuooLh9vfqw_p9AMRFIY=.75bf052d-3086-4f79-8441-c84b514e7260@github.com>

Please review this test-only PR which adds a micro benchmark exploring performance differences between reading entry data sequentially from a `ZipFile` and reading the same entries using `ZipInputStream` wrapping a `BufferedInputStream`.

Spoiler alert: `ZipFile` streams are ~1.8 X slower on my machine compared to `ZipInputStream`:


Benchmark                               (buffered)  (method)  (size)  Mode  Cnt     Score     Error  Units
ReadZipStreams.zipFile                        true  DEFLATED    1024  avgt   15  7871.679 ? 278.719  us/op
ReadZipStreams.zipFile                        true    STORED    1024  avgt   15  4976.571 ?  87.311  us/op
ReadZipStreams.zipInputStream                 true  DEFLATED    1024  avgt   15  4345.494 ?  40.628  us/op
ReadZipStreams.zipInputStream                 true    STORED    1024  avgt   15  2652.063 ?  13.617  us/op


 When not using `BufferedInputStream`, most of the difference disappears, so this is probably related to `ZipFileInputStream`'s lack of buffering:


ReadZipStreams.zipFile                       false  DEFLATED    1024  avgt   15  7980.705 ? 490.846  us/op
ReadZipStreams.zipFile                       false    STORED    1024  avgt   15  4994.301 ?  52.762  us/op
ReadZipStreams.zipInputStream                false  DEFLATED    1024  avgt   15  8367.171 ?  81.631  us/op
ReadZipStreams.zipInputStream                false    STORED    1024  avgt   15  4811.824 ?  47.859  us/op

-------------

Commit messages:
 - Add micro benchmark comparing input stream performance of ZipFile vs ZipInputStream

Changes: https://git.openjdk.org/jdk/pull/21178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340887
  Stats: 118 lines in 1 file changed: 118 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21178/head:pull/21178

PR: https://git.openjdk.org/jdk/pull/21178

From liach at openjdk.org  Wed Sep 25 12:07:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 12:07:36 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <el8WYcDa2xcKAmgVa08BLFsC94L0H0MKik0aH18AmEs=.3b6807c6-c6de-43ee-994a-98e71931a05e@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <el8WYcDa2xcKAmgVa08BLFsC94L0H0MKik0aH18AmEs=.3b6807c6-c6de-43ee-994a-98e71931a05e@github.com>
Message-ID: <S64td0EnVXPG_uVW2Xg44mr3f26JomGgRU51ZVadHoE=.a9031020-8767-46bf-a7c1-ad0f0d788ba1@github.com>

On Wed, 25 Sep 2024 10:02:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2276:
> 
>> 2274:                 var thisClass = cm.thisClass();
>> 2275:                 name = thisClass.asInternalName();
>> 2276:                 sym = thisClass.asSymbol();
> 
> We only use this for determining package name are equal, and sym.packageName() does the similar transformations plus a bit more. Likely not a significant cost compared to the `ClassFile::parse` - but perhaps there's room for a utility method to get the package name directly from an internal name?

This is not part of internal code path so I don't think it is that sensitive

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2440:
> 
>> 2438:         }
>> 2439: 
>> 2440:         record ClassDefiner(Lookup lookup, String name, byte[] bytes, int classFlags, ClassFileDumper dumper) {
> 
> Rename `name` to `internalName`, dropping the explicit `internalName()` method.

Should I rename other existing name vars too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1775101786
PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1775102743

From redestad at openjdk.org  Wed Sep 25 12:13:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 12:13:40 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <S64td0EnVXPG_uVW2Xg44mr3f26JomGgRU51ZVadHoE=.a9031020-8767-46bf-a7c1-ad0f0d788ba1@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <el8WYcDa2xcKAmgVa08BLFsC94L0H0MKik0aH18AmEs=.3b6807c6-c6de-43ee-994a-98e71931a05e@github.com>
 <S64td0EnVXPG_uVW2Xg44mr3f26JomGgRU51ZVadHoE=.a9031020-8767-46bf-a7c1-ad0f0d788ba1@github.com>
Message-ID: <M0onPc9_XfWJLnoVkq139gnD6dCdTuWLfA1OY-GA1MY=.1e56e9fd-f0c9-4176-88e7-bee7a2ea256c@github.com>

On Wed, 25 Sep 2024 12:03:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2276:
>> 
>>> 2274:                 var thisClass = cm.thisClass();
>>> 2275:                 name = thisClass.asInternalName();
>>> 2276:                 sym = thisClass.asSymbol();
>> 
>> We only use this for determining package name are equal, and sym.packageName() does the similar transformations plus a bit more. Likely not a significant cost compared to the `ClassFile::parse` - but perhaps there's room for a utility method to get the package name directly from an internal name?
>
> This is not part of internal code path so I don't think it is that sensitive

Agree - was just thinking out loud on this one. What you have is good enough here.

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2440:
>> 
>>> 2438:         }
>>> 2439: 
>>> 2440:         record ClassDefiner(Lookup lookup, String name, byte[] bytes, int classFlags, ClassFileDumper dumper) {
>> 
>> Rename `name` to `internalName`, dropping the explicit `internalName()` method.
>
> Should I rename other existing name vars too?

AFAICT they already use the record names, so we're not generating redundant code there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1775111423
PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1775110617

From mbaesken at openjdk.org  Wed Sep 25 12:23:04 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 25 Sep 2024 12:23:04 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
Message-ID: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>

There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.

The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

-------------

Commit messages:
 - JDK-8340801

Changes: https://git.openjdk.org/jdk/pull/21184/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21184&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340801
  Stats: 14 lines in 3 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21184/head:pull/21184

PR: https://git.openjdk.org/jdk/pull/21184

From lancea at openjdk.org  Wed Sep 25 12:42:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Sep 2024 12:42:36 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <Dl0z3-17QlfLp9lBOtrZ6Gg4f2kS1JjXXMZrfGCiE8U=.f05680aa-2dfd-4de2-94ec-fb10b7eab099@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
 <Dl0z3-17QlfLp9lBOtrZ6Gg4f2kS1JjXXMZrfGCiE8U=.f05680aa-2dfd-4de2-94ec-fb10b7eab099@github.com>
Message-ID: <ruy1mOJZiB7mJgw0a4fu4QC_HKqVgTX2c35S5uhwl-0=.af8240c1-fb14-4817-a111-668bea581a5d@github.com>

On Wed, 25 Sep 2024 10:12:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on bootstrap and stored in the default CDS archive by 2.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Shift constant values
>  - Update src/java.base/share/classes/java/util/zip/ZipCoder.java
>    
>    Co-authored-by: Eirik Bjorsnos <eirbjo at gmail.com>

Looks fine

please add the appropriate label given there was no test included to the issue prior to committing

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21176#pullrequestreview-2328135339

From thartmann at openjdk.org  Wed Sep 25 12:53:41 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 12:53:41 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <D5Zlo1FLvswE0pqnadyvg-BMyGp-o6ETlbtz9KuK_94=.18cf9806-5320-4d14-9e07-015b88211a39@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Thanks for the reviews Aleksey and Jorn!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2373998723

From duke at openjdk.org  Wed Sep 25 12:58:20 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 25 Sep 2024 12:58:20 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v6]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/34d45238..38f7b79a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=04-05

  Stats: 30 lines in 2 files changed: 7 ins; 3 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From liach at openjdk.org  Wed Sep 25 13:00:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 13:00:37 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <M0onPc9_XfWJLnoVkq139gnD6dCdTuWLfA1OY-GA1MY=.1e56e9fd-f0c9-4176-88e7-bee7a2ea256c@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <el8WYcDa2xcKAmgVa08BLFsC94L0H0MKik0aH18AmEs=.3b6807c6-c6de-43ee-994a-98e71931a05e@github.com>
 <S64td0EnVXPG_uVW2Xg44mr3f26JomGgRU51ZVadHoE=.a9031020-8767-46bf-a7c1-ad0f0d788ba1@github.com>
 <M0onPc9_XfWJLnoVkq139gnD6dCdTuWLfA1OY-GA1MY=.1e56e9fd-f0c9-4176-88e7-bee7a2ea256c@github.com>
Message-ID: <aT5TJ2RVpBOZlSYUKcj0ux_fqAcgKq0YjH9CN2jQlZ4=.56d66a8f-b283-4ef8-ab98-3297805760c8@github.com>

On Wed, 25 Sep 2024 12:10:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Should I rename other existing name vars too?
>
> AFAICT they already use the record names, so we're not generating redundant code there.

I mean the name variable in makeHiddenClassDefiner and makeClassDefiner that leads up here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1775184196

From liach at openjdk.org  Wed Sep 25 13:02:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 13:02:36 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <hJjjJjrwmjQBMYrM9b9ww9ySVrXmOJrhGrWgOBcHrMA=.a5b50804-72cd-4fed-add2-f44e29b6b1d0@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21160#pullrequestreview-2328187090

From redestad at openjdk.org  Wed Sep 25 13:03:39 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 13:03:39 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <aT5TJ2RVpBOZlSYUKcj0ux_fqAcgKq0YjH9CN2jQlZ4=.56d66a8f-b283-4ef8-ab98-3297805760c8@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <el8WYcDa2xcKAmgVa08BLFsC94L0H0MKik0aH18AmEs=.3b6807c6-c6de-43ee-994a-98e71931a05e@github.com>
 <S64td0EnVXPG_uVW2Xg44mr3f26JomGgRU51ZVadHoE=.a9031020-8767-46bf-a7c1-ad0f0d788ba1@github.com>
 <M0onPc9_XfWJLnoVkq139gnD6dCdTuWLfA1OY-GA1MY=.1e56e9fd-f0c9-4176-88e7-bee7a2ea256c@github.com>
 <aT5TJ2RVpBOZlSYUKcj0ux_fqAcgKq0YjH9CN2jQlZ4=.56d66a8f-b283-4ef8-ab98-3297805760c8@github.com>
Message-ID: <nqvTM3n2-djjqqhWvlUrUqRDqjQg3pw-nk7t0Bpawu0=.b97d3a9b-5a72-4566-b22e-60766f5072f9@github.com>

On Wed, 25 Sep 2024 12:58:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> AFAICT they already use the record names, so we're not generating redundant code there.
>
> I mean the name variable in makeHiddenClassDefiner and makeClassDefiner that leads up here.

Ah.. Yeah, either way you like, but if it's an internal name (`foo/Bar`) then including internal in the variable names consistently is good I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21170#discussion_r1775187937

From redestad at openjdk.org  Wed Sep 25 13:07:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 13:07:42 GMT
Subject: RFR: 8340885: Desugar ZipCoder.Comparison [v2]
In-Reply-To: <Dl0z3-17QlfLp9lBOtrZ6Gg4f2kS1JjXXMZrfGCiE8U=.f05680aa-2dfd-4de2-94ec-fb10b7eab099@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
 <Dl0z3-17QlfLp9lBOtrZ6Gg4f2kS1JjXXMZrfGCiE8U=.f05680aa-2dfd-4de2-94ec-fb10b7eab099@github.com>
Message-ID: <MJAboCIPGF-DqUNqEzBhgMDIiLaPYRt8TGPL7Nn75X4=.54ae41de-ac53-4ed9-a483-946989ab74e1@github.com>

On Wed, 25 Sep 2024 10:12:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on bootstrap and stored in the default CDS archive by 2.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Shift constant values
>  - Update src/java.base/share/classes/java/util/zip/ZipCoder.java
>    
>    Co-authored-by: Eirik Bjorsnos <eirbjo at gmail.com>

Thanks! 

> please add the appropriate label given there was no test included to the issue prior to committing

noreg-perf added

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21176#issuecomment-2374028215

From redestad at openjdk.org  Wed Sep 25 13:07:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 13:07:42 GMT
Subject: Integrated: 8340885: Desugar ZipCoder.Comparison
In-Reply-To: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
References: <6Cg0wVNvZv9BtJM3TjSjk_mmmWHP6Mfk6IkA6r0d70Q=.02508d2b-b134-44a2-8811-c282f064a724@github.com>
Message-ID: <v-KSKfJMsR4UjV5wfk6rGV9soSy87V22_8BknAlsa7g=.0f63284b-34ca-44b5-8beb-51687717c220@github.com>

On Wed, 25 Sep 2024 09:15:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on bootstrap and stored in the default CDS archive by 2.

This pull request has now been integrated.

Changeset: d8790aa0
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8790aa0489fe49b499535c31cdfb691003792ff
Stats:     25 lines in 2 files changed: 0 ins; 1 del; 24 mod

8340885: Desugar ZipCoder.Comparison

Reviewed-by: lancea, eirbjo

-------------

PR: https://git.openjdk.org/jdk/pull/21176

From thartmann at openjdk.org  Wed Sep 25 13:30:40 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 25 Sep 2024 13:30:40 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <YhlZ2M_QziE_JMSPBNR-SFR4jNCc8S_fk3PiMOKyi_4=.50a73b38-92d8-4875-8d37-873699a36661@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <YhlZ2M_QziE_JMSPBNR-SFR4jNCc8S_fk3PiMOKyi_4=.50a73b38-92d8-4875-8d37-873699a36661@github.com>
Message-ID: <8t6f6hJsyxXOt57BOfLWazMDcuG6FOhdUV3leYgepz0=.8457df92-2417-4bcc-be9a-5ecd771841e7@github.com>

On Tue, 24 Sep 2024 15:11:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
>> 
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
>> 
>> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
>> 
>> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
>> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
>> 
>> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
>> 
>> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
>> 
>> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
>> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
>> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
>> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
>> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
>> 
>> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent store...
>
> @TobiHartmann Do we need some test tags like "intermittent" for such a chance-based concurrency test?

Thanks for the re-review @liach !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2374088517

From redestad at openjdk.org  Wed Sep 25 13:43:49 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 13:43:49 GMT
Subject: RFR: 8340571: Outline code from the loop in ZipFile.Source.initCen
 [v3]
In-Reply-To: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
References: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
Message-ID: <ozgDEVmdCKft5dXO45QjfX3ZIKrS-_owasQbeyO8Gbk=.792b27ce-991d-4605-bdd4-5fa708929106@github.com>

> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic as possible into the per-entry method processor. This inner method will be called often and JIT optimized earlier in the bootstrap sequence.
> 
> Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both my M1 macbook and my x64 wokstation, while we also improve on relevant throughput microbenchmarks:
> 
> 
> Name               (size) Cnt       Base      Error        Test      Error  Unit  Change
> openCloseZipFile      512  15  61372.449 ? 1197.432   58081.423 ? 1751.988 ns/op   1.06x (p = 0.000*)
> openCloseZipFile     1024  15 117953.727 ? 3202.274  112548.875 ? 5126.665 ns/op   1.05x (p = 0.001*)
> openCloseZipFilex2    512  15  62141.795 ?  674.121   60520.017 ? 2438.346 ns/op   1.03x (p = 0.017 )
> openCloseZipFilex2   1024  15 117959.071 ? 1528.426  111773.937 ? 1604.412 ns/op   1.06x (p = 0.000*)
>   * = significant

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21133/files
  - new: https://git.openjdk.org/jdk/pull/21133/files/f0011e4c..e226b5da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21133&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21133&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21133/head:pull/21133

PR: https://git.openjdk.org/jdk/pull/21133

From liach at openjdk.org  Wed Sep 25 14:50:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 14:50:12 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup [v2]
In-Reply-To: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
Message-ID: <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>

> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Rename to internalName where possible

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21170/files
  - new: https://git.openjdk.org/jdk/pull/21170/files/bd90f8d9..c172d126

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21170&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21170&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21170/head:pull/21170

PR: https://git.openjdk.org/jdk/pull/21170

From redestad at openjdk.org  Wed Sep 25 14:50:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 14:50:12 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup [v2]
In-Reply-To: <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>
Message-ID: <7ZTIJPLXk02CLaMgQiwM5YUfeXT_1S1myi5o1SrTaNQ=.10c000db-a7ce-4d7a-bcc5-e1ffb8334eb7@github.com>

On Wed, 25 Sep 2024 14:47:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to internalName where possible

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21170#pullrequestreview-2328513487

From liach at openjdk.org  Wed Sep 25 14:50:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 14:50:12 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
Message-ID: <DojpHcfjlxZGOw6006A_8Dd27bEddzjI-YYWCL4Ksrk=.bc811ee5-7640-4f67-a74f-ff9924eeba5c@github.com>

On Tue, 24 Sep 2024 22:07:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.

Apparently forgot to push when I re-requested a review after the renames.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21170#issuecomment-2374304742

From redestad at openjdk.org  Wed Sep 25 14:50:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 14:50:12 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup
In-Reply-To: <DojpHcfjlxZGOw6006A_8Dd27bEddzjI-YYWCL4Ksrk=.bc811ee5-7640-4f67-a74f-ff9924eeba5c@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <DojpHcfjlxZGOw6006A_8Dd27bEddzjI-YYWCL4Ksrk=.bc811ee5-7640-4f67-a74f-ff9924eeba5c@github.com>
Message-ID: <H6EVcTDc2zRxZagYkifbzAjNZerb3ptbmxgImR8jUL8=.2a3d584a-725d-45f0-9825-5ed1f1295242@github.com>

On Wed, 25 Sep 2024 14:44:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Apparently forgot to push when I re-requested a review after the renames.

I thought something was off, but on the third refresh the changes came in :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21170#issuecomment-2374309882

From redestad at openjdk.org  Wed Sep 25 15:06:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 15:06:35 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <NPyZirltKKqb7UNu0V9SkmitiIFLFMSnJL-W9eb44r8=.32f9b26d-2476-4efa-8d0d-8f4b7f236e28@github.com>

On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

@eirbjo: an alternative suggested offline by @LanceAndersen is that we merge the two PRs, since they intermingle a bit too much and have the same goal of optimizing initCEN. OK if I merge this into #21133?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20905#issuecomment-2374358554

From liach at openjdk.org  Wed Sep 25 15:44:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 15:44:42 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <wWNKTPCK1YSqVEVn8a-RQZlIM0Jrv6Yrf7PJ-y4OAvY=.d8ae5ebd-43f0-4248-9a47-310c072271b9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <04mDTpAYPyJc_PVg2TQq1Fmvf1p7PgfVJkHDcGETuhA=.723673dc-390e-4c1b-aebb-e9867fd9d665@github.com>
 <RdZoRGPTtamByMOyg8p4Entv_jfHMnIURYQ73aHT8ks=.ea442115-c578-40f9-8517-2f58672aaa18@github.com>
 <wWNKTPCK1YSqVEVn8a-RQZlIM0Jrv6Yrf7PJ-y4OAvY=.d8ae5ebd-43f0-4248-9a47-310c072271b9@github.com>
Message-ID: <pQgjWb7MtirZCeZmcTncGpSjAJNDWApLSvUDzm7jvk8=.882ebf17-c474-47e6-beda-6b4e3b5043b3@github.com>

On Wed, 28 Aug 2024 15:12:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>>> I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`:
>>> 
>>> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637
>> 
>> I am not suggesting link to the CSR, what I was indicating the CSR provides more details  because of the proposed removal.
>> 
>> Comparing to `Thread::stop` is not quite the same, and  the verbiage you are pointing to above was added when the method was [degraded to throw a UOE](https://bugs.openjdk.org/browse/JDK-8277861), not  when it was [deprecated for removal](https://bugs.openjdk.org/browse/JDK-8277861)
>> 
>> The overall usage of ZipError is extremely minimal in the wild at best, from what I can tell was in a catch statement and was not documented to be thrown by any public  API, though was thrown by ZipFile's internal ZipEntryIterator::next
>> 
>> If this was a more heavily used Exception, it would probably warrant further consideration for additional documentation, I am not convinced it is needed here
>
> Thanks @LanceAndersen and @liach for your patient reviews.
> 
> I have updated the Specification section of the CSR and moved it to the Proposed state for an initial round of reviews:
> 
> https://bugs.openjdk.org/browse/JDK-8338663

@eirbjo Can you answer CSR review question about whether to just deprecate the constructor of `ZipError` for removal at the CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2374453344

From eirbjo at openjdk.org  Wed Sep 25 16:11:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 16:11:35 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
In-Reply-To: <NPyZirltKKqb7UNu0V9SkmitiIFLFMSnJL-W9eb44r8=.32f9b26d-2476-4efa-8d0d-8f4b7f236e28@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <NPyZirltKKqb7UNu0V9SkmitiIFLFMSnJL-W9eb44r8=.32f9b26d-2476-4efa-8d0d-8f4b7f236e28@github.com>
Message-ID: <tFrh5amWBMGBjMpao-uROzb-LzGN6zkT8l03bpX5nOo=.e55a317f-4daf-4a30-af9f-6f73dfaa47f9@github.com>

On Wed, 25 Sep 2024 15:03:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> @eirbjo: an alternative suggested offline by @LanceAndersen is that we merge the two PRs, since they intermingle a bit too much and have the same goal of optimizing initCEN. OK if I merge this into #21133?

My first thought was "that also works fine", but then:

I actually see these two PRs as having separate and unrelated goals. One is a performance optimization targeting better / earlier JIT compiled code, the other is performance neutral and simply aims to make the code easier to understand and maintain.

While mixing these together might simplify the review work done here, I think any future maintainer would prefer if they could study these changes independently. To maintain a clean change history, I'd prefer if we could review and integrate them as independent PRs.

The review order of the PRs feels less important for me.  It's fine for me to hold this off and wait for your changes, as you say this one is pretty trivial and easy for me to  merge or redo after your PR is integrated. If this PR is deemed easy to review, then perhaps it's better to get it integrated first.

But if you don't agree, that's also fine! I'll concede and withdraw this PR, no worries.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20905#issuecomment-2374519289

From eirbjo at openjdk.org  Wed Sep 25 16:22:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 16:22:55 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

Eirik Bj?rsn?s 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 zipfile-endhdr
 - Merge branch 'master' into zipfile-endhdr
 - Do not include the END header when reading the CEN section

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20905/files
  - new: https://git.openjdk.org/jdk/pull/20905/files/f0f78601..97ef7283

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20905&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20905&range=00-01

  Stats: 32873 lines in 1053 files changed: 19820 ins; 7264 del; 5789 mod
  Patch: https://git.openjdk.org/jdk/pull/20905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20905/head:pull/20905

PR: https://git.openjdk.org/jdk/pull/20905

From eirbjo at openjdk.org  Wed Sep 25 16:39:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 16:39:48 GMT
Subject: Integrated: 8340684: Reading from an input stream backed by a closed
 ZipFile has no test coverage
In-Reply-To: <V_9qh9hA7lJHKD0-gFN-JObc8r3hs0ouVyATrcvmDdc=.a40afcd7-6b44-4667-b8ca-a193cd15bdeb@github.com>
References: <V_9qh9hA7lJHKD0-gFN-JObc8r3hs0ouVyATrcvmDdc=.a40afcd7-6b44-4667-b8ca-a193cd15bdeb@github.com>
Message-ID: <aXO5Xqy9H9pmZjxTWRU5WytC_cHzyoLCbOD6z1LXXOM=.a7295265-d693-4f00-a351-e72970381bc0@github.com>

On Mon, 23 Sep 2024 18:05:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds test coverage for the case of reading from an input stream obtained using`ZipFile:getInputStream` after the backing `ZipFile` has been closed. 
> 
> The unspecified but long-standing behavior for this unusual use case is to throw `IOException`, but this is not verified by current tests. Adding a test would help prevent regressions in this area.
> 
> The test is parameterized to excercise a variation of stored/deflated entries, and a variation of read behaviors before the `ZipFile` is closed.

This pull request has now been integrated.

Changeset: 0e0b0b0d
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e0b0b0d2626cda032f1500e64f6729554e47038
Stats:     128 lines in 1 file changed: 128 ins; 0 del; 0 mod

8340684: Reading from an input stream backed by a closed ZipFile has no test coverage

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/21142

From liach at openjdk.org  Wed Sep 25 17:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:03:18 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v2]
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <GKg-t65YV-Pwx_WUWaT5pFckkFNSUzheHIyquDvanME=.7a568491-5f13-4cb4-9fe4-5d3964429b0f@github.com>

> 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.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Flip flags, hidden is enabled only by choice
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - Missing changes to commit
 - Condense legacy and modern impl
 - Clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Cleanup...
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - Fixes
 - ... and 2 more: https://git.openjdk.org/jdk/compare/fb703258...16906bfb

-------------

Changes: https://git.openjdk.org/jdk/pull/19356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19356&range=01
  Stats: 82 lines in 6 files changed: 53 ins; 1 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/19356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19356/head:pull/19356

PR: https://git.openjdk.org/jdk/pull/19356

From liach at openjdk.org  Wed Sep 25 17:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:03:18 GMT
Subject: RFR: 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: <aZ9HstlDYKpub8B6r4sTh_If0VbSrHYKrEN4cdPJ5QI=.fc57d345-aad9-4698-a87c-d57c907cc862@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.

Will have to rework since this is in conflict with #19410. Converting into draft for now.

This patch has been reworked. Now the new implementation is opt-in, which should allow for early adoption to ease the transition. Please review the associated CSR and release note as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2133466043
PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2374651015

From liach at openjdk.org  Wed Sep 25 17:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:03:18 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v2]
In-Reply-To: <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
Message-ID: <eOf79lY0E4SPdzlOpco7G-PEHWd0oyDHLt1fgnRSQyM=.16cf0758-36ef-4634-bc9c-acd4a23074c0@github.com>

On Mon, 27 May 2024 00:04:07 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Flip flags, hidden is enabled only by choice
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>>  - Missing changes to commit
>>  - Condense legacy and modern impl
>>  - Clean up
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>  - Cleanup...
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>>  - Fixes
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/fb703258...16906bfb
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 624:
> 
>> 622:             "true".equals(props.getProperty("jdk.disableSerialConstructorChecks"));
>> 623: 
>> 624:         useLegacyProxyImpl &= !useOldSerializableConstructor;
> 
> Suggestion:
> 
>         useLegacyProxyImpl |= useOldSerializableConstructor;

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1631392934

From shade at openjdk.org  Wed Sep 25 17:06:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Sep 2024 17:06:34 GMT
Subject: RFR: 8340838: Clean up MutableCallSite to use explicit release
 fence instead of AtomicInteger
In-Reply-To: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
References: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
Message-ID: <YMk_6BFVnqqQe3Sszw-hCgdwE3WEWdDYZwz_T-S9aaE=.332ead1e-9778-4e8b-ae3e-6793804293fd@github.com>

On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> This implementation code was written in JDK 7, before storeFence was available in JDK 8. We should update this legacy code to make it clear.

I have been harboring doubts `syncAll` even works (`FIXME: NYI` is fun) with a lone barrier for about 10-ish years now. But it is irrelevant for the patch at hand, and kicking out excess `AtomicInteger` is good.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21169#pullrequestreview-2328938024

From dcubed at openjdk.org  Wed Sep 25 17:22:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Sep 2024 17:22:06 GMT
Subject: Integrated: 8340956: ProblemList 4 java/nio/channels/DatagramChannel
 tests on macosx-all
Message-ID: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>

A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.

-------------

Commit messages:
 - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all

Changes: https://git.openjdk.org/jdk/pull/21188/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21188&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340956
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21188.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21188/head:pull/21188

PR: https://git.openjdk.org/jdk/pull/21188

From liach at openjdk.org  Wed Sep 25 17:22:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:22:06 GMT
Subject: Integrated: 8340956: ProblemList 4
 java/nio/channels/DatagramChannel tests on macosx-all
In-Reply-To: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
References: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
Message-ID: <TXxhI-kZt05OwpfFMe0tYRyrUdHQZ2SmqUV2lOZ7JWQ=.28b84e4f-c303-492c-8575-196a9d545b92@github.com>

On Wed, 25 Sep 2024 17:07:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.

These failures happen extremely often on macosx indeed.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21188#pullrequestreview-2328952130

From alanb at openjdk.org  Wed Sep 25 17:22:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Sep 2024 17:22:06 GMT
Subject: Integrated: 8340956: ProblemList 4
 java/nio/channels/DatagramChannel tests on macosx-all
In-Reply-To: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
References: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
Message-ID: <eAnam8O4-PK2S0zcoeir3nU4-MbRDYLPYbJwt_HtoQc=.d687a800-d942-41fa-8211-0706f37abf0f@github.com>

On Wed, 25 Sep 2024 17:07:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21188#pullrequestreview-2328952457

From darcy at openjdk.org  Wed Sep 25 17:22:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 25 Sep 2024 17:22:06 GMT
Subject: Integrated: 8340956: ProblemList 4
 java/nio/channels/DatagramChannel tests on macosx-all
In-Reply-To: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
References: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
Message-ID: <Pi-c7SFs8GrEgIOhtmRmrHpGxklM0lu4FxZxph8Fz-U=.1154fc6e-3fd6-4bed-a4fb-73e9eee2ab03@github.com>

On Wed, 25 Sep 2024 17:07:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21188#pullrequestreview-2328954749

From dfuchs at openjdk.org  Wed Sep 25 17:22:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Sep 2024 17:22:06 GMT
Subject: Integrated: 8340956: ProblemList 4
 java/nio/channels/DatagramChannel tests on macosx-all
In-Reply-To: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
References: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
Message-ID: <p3XPsMaikvyUI0FahGBMa7KzfnUJKL7osXMSwQPrkkE=.50c2d4dd-d45a-40ca-b67f-d043935a9cd8@github.com>

On Wed, 25 Sep 2024 17:07:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21188#pullrequestreview-2328965652

From dcubed at openjdk.org  Wed Sep 25 17:22:07 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Sep 2024 17:22:07 GMT
Subject: Integrated: 8340956: ProblemList 4
 java/nio/channels/DatagramChannel tests on macosx-all
In-Reply-To: <TXxhI-kZt05OwpfFMe0tYRyrUdHQZ2SmqUV2lOZ7JWQ=.28b84e4f-c303-492c-8575-196a9d545b92@github.com>
References: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
 <TXxhI-kZt05OwpfFMe0tYRyrUdHQZ2SmqUV2lOZ7JWQ=.28b84e4f-c303-492c-8575-196a9d545b92@github.com>
Message-ID: <pZ5Mfr6qZc2dZiNJGOQ6LPp4_YQ9YKsabeZQWhTB_xM=.94d6859c-eb14-45fa-a7d8-80c67e714eae@github.com>

On Wed, 25 Sep 2024 17:11:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.
>
> These failures happen extremely often on macosx indeed.

@liach, @AlanBateman, @jddarcy  and @dfuch - Thanks for the lightning fast reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21188#issuecomment-2374701024

From dcubed at openjdk.org  Wed Sep 25 17:22:07 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Sep 2024 17:22:07 GMT
Subject: Integrated: 8340956: ProblemList 4 java/nio/channels/DatagramChannel
 tests on macosx-all
In-Reply-To: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
References: <UEODGGUakUNcii0cjspT3azS6s5uCuV8MyFScIV-Zcw=.af3fd97e-3b52-4d4f-b6d0-e2d1fe6baf14@github.com>
Message-ID: <uDhvEGGyHPGZB_gClrYmV7csvvv32i_oDSL7z1icZNU=.db5acc57-efa0-4537-8540-8e541f1c3fb9@github.com>

On Wed, 25 Sep 2024 17:07:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all.

This pull request has now been integrated.

Changeset: 1b2d40ad
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b2d40addfc5e32229418d29ae90fb440720479e
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all

Reviewed-by: liach, alanb, darcy, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/21188

From duke at openjdk.org  Wed Sep 25 17:25:35 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Wed, 25 Sep 2024 17:25:35 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <ungDDe93EAYB0DDXPbFvKL7Zag0XlmAy90udH6cFa_k=.938ce5ce-62be-4aa3-8d6f-bcd99ec7ad76@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21160#pullrequestreview-2328987501

From jlu at openjdk.org  Wed Sep 25 18:28:02 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Sep 2024 18:28:02 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v2]
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <_Al64z5erbVBKbTCHjVzvVIWZ76tZ6SoKqRWslbhDPs=.f4016efb-9ec5-4725-9391-048e15747392@github.com>

> Please review this PR which removes usages of Applet within the corelibs tests. This includes both code usage as well as occurrences of the word.
> 
> There were more files found than the ones included in this PR, please see the comment on the JBS issue for the reason why they were not included. In general, I removed the file if the entirety was focused on Applet, otherwise I removed the portions applicable.

Justin Lu 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:

 - update TEST.groups with DefaultTimeZoneTest.java removal
 - Merge branch 'master' into JDK-8340326-tests-appletRemoval
 - init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21096/files
  - new: https://git.openjdk.org/jdk/pull/21096/files/a50c1972..cc860712

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=00-01

  Stats: 153402 lines in 749 files changed: 148791 ins; 1873 del; 2738 mod
  Patch: https://git.openjdk.org/jdk/pull/21096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21096/head:pull/21096

PR: https://git.openjdk.org/jdk/pull/21096

From liach at openjdk.org  Wed Sep 25 18:31:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 18:31:38 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup [v2]
In-Reply-To: <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>
Message-ID: <THHCani3Lc85EjYgbSWw5r82S7r6XpALxr7KgIVnhY0=.1473281b-f460-482f-86de-291a123d6c4a@github.com>

On Wed, 25 Sep 2024 14:50:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to internalName where possible

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21170#issuecomment-2374866472

From liach at openjdk.org  Wed Sep 25 18:31:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 18:31:40 GMT
Subject: RFR: 8340838: Clean up MutableCallSite to use explicit release
 fence instead of AtomicInteger
In-Reply-To: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
References: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
Message-ID: <mjbCIzQpQ1GAKuFZ9Fx_N9QHz-d8puY5QqCymnhsdRk=.d3f5a48f-9941-4e9b-94f4-da4d499d9983@github.com>

On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> This implementation code was written in JDK 7, before storeFence was available in JDK 8. We should update this legacy code to make it clear.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21169#issuecomment-2374866169

From liach at openjdk.org  Wed Sep 25 18:31:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 18:31:40 GMT
Subject: Integrated: 8340838: Clean up MutableCallSite to use explicit release
 fence instead of AtomicInteger
In-Reply-To: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
References: <3a2c07RGMtyubbCVQlp_6z9-rAWTFxVbHhL9g7Q8mLs=.30ac701b-77ce-410b-9a5b-8646cb5e3a10@github.com>
Message-ID: <AtbY46nG0Ym2x9pw2LwzYRYubOtA8A4-9ZH-hHpauNw=.d3bdb0ba-d9c1-4176-881b-811ae51aed62@github.com>

On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> This implementation code was written in JDK 7, before storeFence was available in JDK 8. We should update this legacy code to make it clear.

This pull request has now been integrated.

Changeset: df1959fd
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df1959fd7a57f11839d58858bab4ea61f5b2bb8d
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger

Reviewed-by: jrose, redestad, shade

-------------

PR: https://git.openjdk.org/jdk/pull/21169

From liach at openjdk.org  Wed Sep 25 18:34:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 18:34:44 GMT
Subject: Integrated: 8340831: Simplify simple validation for class definition
 in MethodHandles.Lookup
In-Reply-To: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
Message-ID: <t3LQ-iMCkp75shBui9Vzsq6pRYUC-22i_NeDM-U401A=.bf27ec3f-8011-45c8-a6f1-157c8d3bdd1f@github.com>

On Tue, 24 Sep 2024 22:07:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.

This pull request has now been integrated.

Changeset: 84751cbf
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84751cbfddf69bd9ed6bc5c39f8e056009440331
Stats:     147 lines in 2 files changed: 19 ins; 62 del; 66 mod

8340831: Simplify simple validation for class definition in MethodHandles.Lookup

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/21170

From liach at openjdk.org  Wed Sep 25 18:54:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 18:54:02 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
Message-ID: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>

@cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.

Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

-------------

Commit messages:
 - Cleanup after merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Compile error
 - Redundant import
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - 8338544: Dedicated Array class descriptor implementation

Changes: https://git.openjdk.org/jdk/pull/20665/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338544
  Stats: 384 lines in 11 files changed: 244 ins; 108 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From duke at openjdk.org  Wed Sep 25 18:54:03 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 25 Sep 2024 18:54:03 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <qcutkw3RrEnk30fBDAv6Q5dodvMm68MsF2iU2ACSuPQ=.3887c11d-4e6d-4325-8f1d-c7a6913ed118@github.com>

On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Apparently, changing method?`default`?ness requires?a?CSR (even?for?fully sealed?hierarchies), but?I?can?t find?the?PR where?I?was informed?of?this.

--------------------------------------------------------------------------------

Using?`return this?instanceof <type>ClassDescImpl` might?allow **C2**?to?better avoid megamorphic virtual?invocations (see?[GH?17488]), but?this?needs to?be?benchmarked:

[GH?17488]: https://github.com/openjdk/jdk/pull/17488

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 237:

> 235:      */
> 236:     default boolean isArray() {
> 237:         return false;

Suggestion:

        return this instanceof ArrayClassDescImpl;

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 246:

> 244:      */
> 245:     default boolean isPrimitive() {
> 246:         return false;

Suggestion:

        return this instanceof PrimitiveClassDescImpl;

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 255:

> 253:      */
> 254:     default boolean isClassOrInterface() {
> 255:         return false;

Suggestion:

        return this instanceof ReferenceClassDescImpl;

-------------

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2263259130
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1732794261
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1732794721
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1732795070

From liach at openjdk.org  Wed Sep 25 18:54:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 18:54:03 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <1ezijSQ1u25st4o3WxACaYHTblVoD-_6ddmSyR-DPrw=.07d56fd9-09b0-42ad-96b3-c779deb01fbf@github.com>

On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

I know this requires a CSR; it's just not created due to this still being a draft.

The main purpose of this is still for speeding up stack map generation; the results are not confirmed yet, so this patch is on hold.

For megamorphic call site thing, the regular workload would be like:

if (c.isArray()) doArrayStuff(c);
if (c.isClassOrInterface()) doClassOrInterfaceStuff(c);

I think polymorphism is fine here, as after the check we usually go straight to perform type-specific operations like `componentType()`; or sometimes a method expects the input ClassDesc to be always primitive/class or interface/array, which won't lead to profile pollutions. This concern might be more valid for `descriptorString` I suppose.

Confirmed this is performance-wise neutral for startup. Ready for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20665#issuecomment-2313134513
PR Comment: https://git.openjdk.org/jdk/pull/20665#issuecomment-2374901141

From eirbjo at openjdk.org  Wed Sep 25 19:07:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 19:07:34 GMT
Subject: RFR: 8340571: Outline code from the loop in ZipFile.Source.initCen
 [v3]
In-Reply-To: <ozgDEVmdCKft5dXO45QjfX3ZIKrS-_owasQbeyO8Gbk=.792b27ce-991d-4605-bdd4-5fa708929106@github.com>
References: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
 <ozgDEVmdCKft5dXO45QjfX3ZIKrS-_owasQbeyO8Gbk=.792b27ce-991d-4605-bdd4-5fa708929106@github.com>
Message-ID: <CmxHiohEJvSx3nkhytlKhA_lFPTnjFeoTXpnp7WVRgA=.afa58551-66c1-4cfd-815a-5c733f570a61@github.com>

On Wed, 25 Sep 2024 13:43:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic as possible into the per-entry method processor. This inner method will be called often and JIT optimized earlier in the bootstrap sequence.
>> 
>> Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both my M1 macbook and my x64 wokstation, while we also improve on relevant throughput microbenchmarks:
>> 
>> 
>> Name               (size) Cnt       Base      Error        Test      Error  Unit  Change
>> openCloseZipFile      512  15  61372.449 ? 1197.432   58081.423 ? 1751.988 ns/op   1.06x (p = 0.000*)
>> openCloseZipFile     1024  15 117953.727 ? 3202.274  112548.875 ? 5126.665 ns/op   1.05x (p = 0.001*)
>> openCloseZipFilex2    512  15  62141.795 ?  674.121   60520.017 ? 2438.346 ns/op   1.03x (p = 0.017 )
>> openCloseZipFilex2   1024  15 117959.071 ? 1528.426  111773.937 ? 1604.412 ns/op   1.06x (p = 0.000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

There is a lot going on in this PR..

I've been playing with similar, but different ideas lately and I'm wondering if we could get away with less intrusive changes and still boost performance. 

Instead of pushing everything into `processNextCENEntry`, how about we instead extract methods for checking the fixed-length CEN header and for checking the variable-length CEN header fields (headerSize, extra and comment)?

Here's a sketch of what I'm thinking: https://github.com/openjdk/jdk/compare/master...eirbjo:initCEN-extract-validation?expand=0

This PR:


Benchmark                       (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15  104987.960 ? 4191.855  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  172605.991 ? 3546.599  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  113737.426 ? 5797.246  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  189276.928 ? 3195.026  ns/op

  
My branch 


Benchmark                       (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15  100435.644 ? 2862.724  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  165181.306 ? 2445.885  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  103644.570 ? 1615.982  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  170362.938 ? 3421.632  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21133#issuecomment-2374942705

From redestad at openjdk.org  Wed Sep 25 19:49:39 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 19:49:39 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
Message-ID: <_Elv50A129vIpgatOrOzfLBCj_nUfCosrJtL8t3Sd28=.1a813011-ce74-41c1-9ca3-c1f485fe1d2b@github.com>

On Wed, 25 Sep 2024 16:22:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
>> 
>> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
>> 
>> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
>> 
>> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
>> 
>> Testing:
>> 
>> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
>> 
>> The `ZipFileOpen` benchmark seems neutral to this change.
>
> Eirik Bj?rsn?s 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 zipfile-endhdr
>  - Merge branch 'master' into zipfile-endhdr
>  - Do not include the END header when reading the CEN section

LGTM. Simplifies a bit and allows for another 22 bytes of CEN.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1740:

> 1738:                 }
> 1739:                 // read in the CEN
> 1740:                 if (end.cenlen > MAX_CEN_SIZE) {

We'd be throwing an OOMError today if we soared too close to the limit (`Integer.MAX_VALUE - ENDHDR - 2` and above), then throw `zerror` if we go beyond the limit. With these changes we change to throw `zerror` exclusively. An OOME can of course still be thrown from any subsequent allocation on a _real_ OOM, so I'm not sure how valuable this edge case trimming is.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20905#pullrequestreview-2329393055
PR Review Comment: https://git.openjdk.org/jdk/pull/20905#discussion_r1775907509

From redestad at openjdk.org  Wed Sep 25 19:58:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 25 Sep 2024 19:58:40 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <mFWB4NbqeDN7VsWr2pFMq3mYlx-Pm1Hjh7OkLLkugJg=.a0597e0b-c55c-414a-a429-7da7866ee62e@github.com>

On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

LGTM. Always a bit queasy to add a third to a nice pair of classes, but if this ever shows up as a problem on benchmarks we can revisit and think of alternatives (such as adding a rank field in each impl).

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 79:

> 77:     private static final ClassDesc CD_LambdaForm_Name = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/LambdaForm$Name;");
> 78:     private static final ClassDesc CD_LoopClauses = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/MethodHandleImpl$LoopClauses;");
> 79:     private static final ClassDesc CD_Object_array  = CD_Object.arrayType();

I guess `CD_Object.arrayType()` shows up often enough now - even once _in_ `java.lang.constant.ConstantDescs` - that we might as well pin it down as a constant somewhere (`ConstantDescs` is a candidate location, but that will take a CSR).

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2329407468
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1775916278

From liach at openjdk.org  Wed Sep 25 20:03:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 20:03:35 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <mFWB4NbqeDN7VsWr2pFMq3mYlx-Pm1Hjh7OkLLkugJg=.a0597e0b-c55c-414a-a429-7da7866ee62e@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <mFWB4NbqeDN7VsWr2pFMq3mYlx-Pm1Hjh7OkLLkugJg=.a0597e0b-c55c-414a-a429-7da7866ee62e@github.com>
Message-ID: <gnGD55EqH3a5xpN5TPdf1zfMLg7VDUxMu-iglw0NMBU=.8ef4b834-562d-45ee-86e4-9f34da999a12@github.com>

On Wed, 25 Sep 2024 19:53:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 79:
> 
>> 77:     private static final ClassDesc CD_LambdaForm_Name = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/LambdaForm$Name;");
>> 78:     private static final ClassDesc CD_LoopClauses = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/MethodHandleImpl$LoopClauses;");
>> 79:     private static final ClassDesc CD_Object_array  = CD_Object.arrayType();
> 
> I guess `CD_Object.arrayType()` shows up often enough now - even once _in_ `java.lang.constant.ConstantDescs` - that we might as well pin it down as a constant somewhere (`ConstantDescs` is a candidate location, but that will take a CSR).

This patch already has a CSR for trivial signature changes. The real difficulty lies in how we should name our new array class descriptors, `Object_array` or `ObjectArray` or what else?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1775924591

From liach at openjdk.org  Wed Sep 25 20:03:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 20:03:36 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <gnGD55EqH3a5xpN5TPdf1zfMLg7VDUxMu-iglw0NMBU=.8ef4b834-562d-45ee-86e4-9f34da999a12@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <mFWB4NbqeDN7VsWr2pFMq3mYlx-Pm1Hjh7OkLLkugJg=.a0597e0b-c55c-414a-a429-7da7866ee62e@github.com>
 <gnGD55EqH3a5xpN5TPdf1zfMLg7VDUxMu-iglw0NMBU=.8ef4b834-562d-45ee-86e4-9f34da999a12@github.com>
Message-ID: <IQcb7ziiEnShoto3oMu1WjHcDUDPuMQ5_lM3VODIi9o=.9f762441-e078-410e-bb1a-95260af63de0@github.com>

On Wed, 25 Sep 2024 20:00:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 79:
>> 
>>> 77:     private static final ClassDesc CD_LambdaForm_Name = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/LambdaForm$Name;");
>>> 78:     private static final ClassDesc CD_LoopClauses = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/MethodHandleImpl$LoopClauses;");
>>> 79:     private static final ClassDesc CD_Object_array  = CD_Object.arrayType();
>> 
>> I guess `CD_Object.arrayType()` shows up often enough now - even once _in_ `java.lang.constant.ConstantDescs` - that we might as well pin it down as a constant somewhere (`ConstantDescs` is a candidate location, but that will take a CSR).
>
> This patch already has a CSR for trivial signature changes. The real difficulty lies in how we should name our new array class descriptors, `Object_array` or `ObjectArray` or what else?

That said, can you leave a quick review on CSR https://bugs.openjdk.org/browse/JDK-8340963 too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1775925133

From eirbjo at openjdk.org  Wed Sep 25 20:33:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Sep 2024 20:33:37 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <_Elv50A129vIpgatOrOzfLBCj_nUfCosrJtL8t3Sd28=.1a813011-ce74-41c1-9ca3-c1f485fe1d2b@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
 <_Elv50A129vIpgatOrOzfLBCj_nUfCosrJtL8t3Sd28=.1a813011-ce74-41c1-9ca3-c1f485fe1d2b@github.com>
Message-ID: <R7xfl1VEGMTtHNIygJbmrjNCVcbKzePSN_wcqCUGaDI=.851dd7d7-ae72-4531-a400-37a2b2d8a307@github.com>

On Wed, 25 Sep 2024 19:44:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We'd be throwing an OOMError today if we soared too close to the limit (Integer.MAX_VALUE - ENDHDR - 2 and above), then throw zerror if we go beyond the limit. 

I think you might be off by one there :)

The current code incorrectly fails to reject a CEN size of `Integer.MAX_VALUE - ENDHDR - 1`, and instead cause an OOME for exceeding the implementation limit of int[]. The size `Integer.MAX_VALUE - ENDHDR - 2` is allowed, as it should.

So the existing code was off-by-one in that it allowed exactly one CEN size which was larger than the implementation limit.

Yes, I'd be surprised if this fix gets any user excited. But I think from a maintainer's point of view, it may be easier to understand code when it's stricly correct since it removes any reason to ponder why the code is almost, but not completely correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20905#discussion_r1775957317

From smarks at openjdk.org  Wed Sep 25 20:51:44 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 25 Sep 2024 20:51:44 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v3]
In-Reply-To: <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
Message-ID: <dKtiS_OzJBR_h2Dc964t46RuEQVq7y3ewmwBSoozXNY=.5e652e75-e142-4ffc-a1ba-bf6d0713092f@github.com>

On Fri, 26 Apr 2024 22:27:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Add test to ensure reproducible iteration order
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Copyright year, revert changes for non-few element collections
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/a920af23...70583024

src/java.base/share/classes/java/util/ImmutableCollections.java line 676:

> 674:                 return Collections.singletonSpliterator(e0);
> 675:             }
> 676:             return super.spliterator();

Not a big deal, but I prefer using if/else for situations like this where the then-part and else-part are equal in size and are conceptually at the same level. (As opposed to a check for a quick special case, where an early return is sensible, followed by the main logic at the method's top level.) Code in the rest of the file is similar, I think.

(yes, I'm aware that this takes an extra line)

src/java.base/share/classes/java/util/ImmutableCollections.java line 934:

> 932:                 return Collections.singletonSpliterator(e0);
> 933:             }
> 934:             return super.spliterator();

Prefer if/else, as noted above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1775972767
PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1775973150

From smarks at openjdk.org  Wed Sep 25 20:55:39 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 25 Sep 2024 20:55:39 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <sVy1U9oiZedcVVRg1-NMlkNZbo92lnhybYy3DORfrKI=.5549b0fe-7119-4dc9-b46b-d118c3af48db@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
 <8I6TzPUv9WRYWHnCz6NZI9y9Zo5Lgoy-WRjqeLtUOuw=.31bd7d2a-4104-480d-bf22-ae395f80222e@github.com>
 <F-fcyYin-zakkqs4sn2Jdr0RyTzf_JSKNT6jSbEqNxo=.c40bf9c6-aba7-4766-a17a-cf203feaeb68@github.com>
 <sVy1U9oiZedcVVRg1-NMlkNZbo92lnhybYy3DORfrKI=.5549b0fe-7119-4dc9-b46b-d118c3af48db@github.com>
Message-ID: <0K-MfKXfHNa6osK9y_XlJuD9kDRNlsMNZ5Pia98Gw2Q=.51d0dfab-ac97-4e1c-b1f2-e7717adcf979@github.com>

On Fri, 22 Mar 2024 09:25:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Benchmark                        Mode  Cnt    Score   Error   Units
>> ImmutableColls.forEachOverList  thrpt   15  361.423 ? 8.751  ops/us
>> ImmutableColls.forEachOverSet   thrpt   15   79.158 ? 5.064  ops/us
>> ImmutableColls.getOrDefault     thrpt   15  244.012 ? 0.943  ops/us
>> ImmutableColls.iterateOverList  thrpt   15  152.598 ? 3.687  ops/us
>> ImmutableColls.iterateOverSet   thrpt   15   61.969 ? 4.453  ops/us
>> 
>> The 3 results are also available at https://gist.github.com/f0b4336e5b1cf9c5299ebdbcd82232bf, where baseline is the master this patch currently is based on (which has WhiteBoxResizeTest failures), patch-0 being the current code, and patch-1 being your proposal (uncommited patch below).
>> 
>> diff --git a/src/java.base/share/classes/java/util/ImmutableCollections.java b/src/java.base/share/classes/java/util/ImmutableCollections.java
>> index fc232a521fb..f38b093cf60 100644
>> --- a/src/java.base/share/classes/java/util/ImmutableCollections.java
>> +++ b/src/java.base/share/classes/java/util/ImmutableCollections.java
>> @@ -916,12 +916,9 @@ public <T> T[] toArray(T[] a) {
>>          @Override
>>          @SuppressWarnings("unchecked")
>>          public void forEach(Consumer<? super E> action) {
>> -            if (e1 == EMPTY) {
>> -                action.accept(e0); // implicit null check
>> -            } else {
>> -                action.accept(REVERSE ? (E)e1 : e0); // implicit null check
>> -                action.accept(REVERSE ? e0 : (E)e1);
>> -            }
>> +            action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E) e1); // implicit null check
>> +            if (e1 != EMPTY)
>> +                action.accept(!REVERSE ? (E) e1 : e0);
>>          }
>>  
>>          @Override
>> 
>> 
>> 
>> My testing shows that the existing version I have is most likely faster than your proposed version.
>> 
>> Also note that the test failures are from WhiteBoxResizeTest that's fixed in latest master; I decide not to pull as not to invalidate the existing benchmark baselines.
>
> Thanks. I was mostly trying to gauge what the bottleneck might be.

Another alternative is this:

            if (e1 == EMPTY) {
                action.accept(e0); // implicit null check
            } else if (REVERSE) {
                action.accept((E)e1); // implicit null check
                action.accept(e0);
            } else {
                action.accept(e0); // implicit null check
                action.accept((E)e1);
            }

I don't care about speed, so don't benchmark unless you're really really curious for yourself. I'm more concerned about clarity. The two ternary operators are a bit weird. My suggestion is bulkier but maybe clearer -- or maybe not.

There is also the fact that the fields are `E e0` and `Object e1` which adds clutter from casting along with some unpleasant asymmetry. But that's a separate matter.

Anyway I'm not so fond of my suggestion, so I won't advocate for it strenuously. Mostly just putting out for discussion. The current code is probably fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1775979779

From naoto at openjdk.org  Wed Sep 25 21:39:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Sep 2024 21:39:38 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v2]
In-Reply-To: <_Al64z5erbVBKbTCHjVzvVIWZ76tZ6SoKqRWslbhDPs=.f4016efb-9ec5-4725-9391-048e15747392@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <_Al64z5erbVBKbTCHjVzvVIWZ76tZ6SoKqRWslbhDPs=.f4016efb-9ec5-4725-9391-048e15747392@github.com>
Message-ID: <6w7rVGmC0gq6zIzWR-xx9TOrJJUmXfsGi-qMDNImNb8=.a6ed72dd-be9e-4598-98ab-d4e626ae207f@github.com>

On Wed, 25 Sep 2024 18:28:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>
> Justin Lu 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:
> 
>  - update TEST.groups with DefaultTimeZoneTest.java removal
>  - Merge branch 'master' into JDK-8340326-tests-appletRemoval
>  - init

Removing `test/jdk/java/util/TimeZone/DefaultTimeZoneTest.*` looks good to me. It's a manual test that involves underlying OS settings manipulation which cannot be automated.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21096#pullrequestreview-2329580972

From jlu at openjdk.org  Wed Sep 25 22:06:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Sep 2024 22:06:55 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v3]
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <CksjIVf3MBzFgUAWwcP-o29HfrZXq1kh1bVwNFYkCXQ=.22e608ec-9bdf-42fd-8d48-1cc86e1cbbda@github.com>

> Please review this PR which removes usages of Applet within the corelibs tests.
> 
> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  restore DefaultTimeZoneTest.java as a manual test using PassFailJFrame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21096/files
  - new: https://git.openjdk.org/jdk/pull/21096/files/cc860712..6b2c060b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=01-02

  Stats: 120 lines in 2 files changed: 119 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21096/head:pull/21096

PR: https://git.openjdk.org/jdk/pull/21096

From jlu at openjdk.org  Wed Sep 25 22:06:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Sep 2024 22:06:55 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v2]
In-Reply-To: <6w7rVGmC0gq6zIzWR-xx9TOrJJUmXfsGi-qMDNImNb8=.a6ed72dd-be9e-4598-98ab-d4e626ae207f@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <_Al64z5erbVBKbTCHjVzvVIWZ76tZ6SoKqRWslbhDPs=.f4016efb-9ec5-4725-9391-048e15747392@github.com>
 <6w7rVGmC0gq6zIzWR-xx9TOrJJUmXfsGi-qMDNImNb8=.a6ed72dd-be9e-4598-98ab-d4e626ae207f@github.com>
Message-ID: <x4pYSyIs1muERuNXQNYW8lS6sYParoTBzks3HwtgBEA=.1f847fdd-303b-4eb5-8fc1-e4d6ff31b527@github.com>

On Wed, 25 Sep 2024 21:36:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing `test/jdk/java/util/TimeZone/DefaultTimeZoneTest.*` looks good to me. It's a manual test that involves underlying OS settings manipulation which cannot be automated.

As we previously spoke offline, I did not think there was much value in preserving the test. 
However, I realize it is a unique test that does validate that the runtime detects the "Automatically adjust clock for daylight saving changes" setting correctly on Windows. I preserved it and replaced the `Applet` overhead with `PassFailJFrame` in the most recent commit. Not sure if it will be ran by anyone as it is manual, but at least we can verify the setting if needed and the test history is preserved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21096#issuecomment-2375345354

From prr at openjdk.org  Wed Sep 25 22:20:33 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Sep 2024 22:20:33 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v2]
In-Reply-To: <x4pYSyIs1muERuNXQNYW8lS6sYParoTBzks3HwtgBEA=.1f847fdd-303b-4eb5-8fc1-e4d6ff31b527@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <_Al64z5erbVBKbTCHjVzvVIWZ76tZ6SoKqRWslbhDPs=.f4016efb-9ec5-4725-9391-048e15747392@github.com>
 <6w7rVGmC0gq6zIzWR-xx9TOrJJUmXfsGi-qMDNImNb8=.a6ed72dd-be9e-4598-98ab-d4e626ae207f@github.com>
 <x4pYSyIs1muERuNXQNYW8lS6sYParoTBzks3HwtgBEA=.1f847fdd-303b-4eb5-8fc1-e4d6ff31b527@github.com>
Message-ID: <SLYhN5rw-TRy9eld9YK2ySPF2Dzy5Qvh6NOT37HGKN8=.c4a7fcc7-038f-45e4-ac6c-3875a8cd6402@github.com>

On Wed, 25 Sep 2024 22:03:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>  Not sure if it will be ran by anyone as it is manual, 

I don't know about other vendors, but for Oracle, manual tests are run at least once on every release some time after RDP1 and before RDP2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21096#issuecomment-2375365153

From naoto at openjdk.org  Wed Sep 25 22:37:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Sep 2024 22:37:34 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v3]
In-Reply-To: <CksjIVf3MBzFgUAWwcP-o29HfrZXq1kh1bVwNFYkCXQ=.22e608ec-9bdf-42fd-8d48-1cc86e1cbbda@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <CksjIVf3MBzFgUAWwcP-o29HfrZXq1kh1bVwNFYkCXQ=.22e608ec-9bdf-42fd-8d48-1cc86e1cbbda@github.com>
Message-ID: <ukjR5fb1r_aN1iB_8hnPg9B9-CtzcqG3HJU93wzuFLw=.50a2802f-d478-42c3-983d-0c2688867502@github.com>

On Wed, 25 Sep 2024 22:06:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/sun/net/www/ParseUtil_6380332.java
>>   - Outdated test that checks a SunTea applet
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore DefaultTimeZoneTest.java as a manual test using PassFailJFrame

test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 29:

> 27:  * @summary Ensure that Java detects the platform time zone correctly, even
> 28:  * if changed during runtime. Also ensure that the system time zone detection code
> 29:  * detects the "Automatically adjust clock for daylight saving changes" setting

Probably taking this opportunity, changing the wording/instructions aligned with "Settings app", instead of deprecated "Control Panel" would be good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21096#discussion_r1776065785

From darcy at openjdk.org  Wed Sep 25 23:02:44 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 25 Sep 2024 23:02:44 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight"
Message-ID: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>

Add citation of the second edition of "Hacker's Delight".

-------------

Commit messages:
 - JDK-8340981: Update citations to "Hacker's Delight"

Changes: https://git.openjdk.org/jdk/pull/21194/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21194&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340981
  Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21194/head:pull/21194

PR: https://git.openjdk.org/jdk/pull/21194

From liach at openjdk.org  Wed Sep 25 23:08:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 23:08:39 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight"
In-Reply-To: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
Message-ID: <LJnhbsGJs74_A7Zh6kTnahJ6ILoFCE2wPsfiGK3Csws=.4d618f31-05c4-41d2-b681-447984ed65d6@github.com>

On Wed, 25 Sep 2024 22:58:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add citation of the second edition of "Hacker's Delight".

Can we update the references in `compress` and `expand`? They refer to this book's sections, and seems they are from different sections in different editions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21194#issuecomment-2375423691

From bpb at openjdk.org  Wed Sep 25 23:11:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 25 Sep 2024 23:11:34 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight"
In-Reply-To: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
Message-ID: <MFrXVTG6EwHMXLokI74shdZNAANklymNjZwHo5IBBOY=.e713a35e-02ec-4571-b1c3-9bb3bc1e314c@github.com>

On Wed, 25 Sep 2024 22:58:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add citation of the second edition of "Hacker's Delight".

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21194#pullrequestreview-2329681709

From darcy at openjdk.org  Wed Sep 25 23:23:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 25 Sep 2024 23:23:43 GMT
Subject: RFR: 8340983: Use index and definition tags in Object and Double
Message-ID: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>

Simple change to add a few more index tags on terms related to equality and equivalence.

-------------

Commit messages:
 - JDK-8340983: Use index and definition tags in Object and Double

Changes: https://git.openjdk.org/jdk/pull/21195/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340983
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21195/head:pull/21195

PR: https://git.openjdk.org/jdk/pull/21195

From bpb at openjdk.org  Wed Sep 25 23:28:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 25 Sep 2024 23:28:35 GMT
Subject: RFR: 8340983: Use index and definition tags in Object and Double
In-Reply-To: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>
References: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>
Message-ID: <YtSPfFQ0lLDFXaky0ztzUKZXii77Bn70Kpxd8WEe6rM=.eca1b69c-5465-4855-b98e-fc40c1f7b30b@github.com>

On Wed, 25 Sep 2024 23:17:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to add a few more index tags on terms related to equality and equivalence.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21195#pullrequestreview-2329695662

From jlu at openjdk.org  Wed Sep 25 23:32:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Sep 2024 23:32:08 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v4]
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <5R8L6xIMINEPo0g5YleaQTtJ3LHMvYRbMmBX6C-buBI=.8d3491c8-4457-41df-a3d2-a4034adf4b93@github.com>

> Please review this PR which removes usages of Applet within the corelibs tests.
> 
> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
> 
> The following files were removed,
> 
> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>   - Test runner is no longer an Applet, so not needed
> - test/jdk/sun/net/www/ParseUtil_6380332.java
>   - Outdated test that checks a SunTea applet
> - test/jdk/java/net/Socket/SocketImplTest.java
>   - An old Applet test missing Jtreg tags.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: update wording of instructions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21096/files
  - new: https://git.openjdk.org/jdk/pull/21096/files/6b2c060b..603e40fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21096/head:pull/21096

PR: https://git.openjdk.org/jdk/pull/21096

From liach at openjdk.org  Wed Sep 25 23:42:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 23:42:33 GMT
Subject: RFR: 8340983: Use index and definition tags in Object and Double
In-Reply-To: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>
References: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>
Message-ID: <cs0w77vSQQUpi2bLevUNqUqADLPYs4C77sXpfLEOJYk=.67ba233d-b70d-41ed-9620-3eceefa188bf@github.com>

On Wed, 25 Sep 2024 23:17:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to add a few more index tags on terms related to equality and equivalence.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21195#pullrequestreview-2329705401

From liach at openjdk.org  Thu Sep 26 00:13:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 00:13:36 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <lW5HOrJ8HUyseBJNvQQXYarR0nuulqgLkZ9NAzwIF2M=.f27bfd21-6b77-49d3-a869-39c7f5ce831a@github.com>

On Mon, 16 Sep 2024 17:50:52 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
> 
> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
> 
> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
> 
> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
> 
> So we make this build in advance, and use a static array for values referred more than once.
> 
> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 669:

> 667:                         CLASS_INIT_NAME,
> 668:                         MTD_void,
> 669:                         ACC_PUBLIC | ACC_STATIC,

Suggestion:

                        ACC_STATIC,

By convention, we simply set the static flag without anything else set.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1248:

> 1246:                             methodName,
> 1247:                             MethodTypeDesc.of(CD_EXPORTS.arrayType()),
> 1248:                             ACC_PRIVATE | ACC_FINAL | ACC_STATIC,

Just curious, why do we mark our split provider methods final? The final flag is only used for hiding.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1427:

> 1425:                     var methodName = "module" + index + "Packages";
> 1426:                     addModuleHelpers(clb -> {
> 1427:                     clb.withMethodBody(

We should indent this lambda.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1598:

> 1596: 
> 1597:             int counterStoredValues = 0;
> 1598:             ClassDesc owner;

Suggestion:

            final ClassDesc owner;

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1804:

> 1802: 
> 1803:         static <T extends Enum<T>> BiConsumer<CodeBuilder, T> getEnumLoader(ClassDesc enumClassDesc) {
> 1804:             return (cob, element) -> cob.getstatic(enumClassDesc, element.toString(), enumClassDesc);

Suggestion:

            return (cob, element) -> cob.getstatic(enumClassDesc, element.name(), enumClassDesc);

test/jdk/tools/jlink/JLink3500Packages.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

test/jdk/tools/jlink/JLink3500Packages.java line 35:

> 33: /*
> 34:  * @test
> 35:  * @summary Make sure that 4000 packages in a uber jar can be linked using jlink.

Should we mention that the number 3500 or 4000 is an arbitrary large number greater than `ModuleDescriptorBuilder.SET_SIZE_THRESHOLD` to trigger the provider method generation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776117490
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776117924
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776110978
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776113761
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776114256
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776123965
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776108517

From ccheung at openjdk.org  Thu Sep 26 00:49:20 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 26 Sep 2024 00:49:20 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v5]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <nLhPjQbCLgZW2eNpwkeTwp0StAxDBhb_u8Y3HRaukmE=.86c9ae91-ddce-4493-a888-665f8f7f6589@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/661615cb..d96d78f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=03-04

  Stats: 25 lines in 5 files changed: 10 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From ccheung at openjdk.org  Thu Sep 26 00:49:21 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 26 Sep 2024 00:49:21 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
Message-ID: <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>

On Wed, 25 Sep 2024 00:11:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix indentation
>
> src/hotspot/share/cds/filemap.cpp line 956:
> 
>> 954:   }
>> 955:   // module paths are stored in sorted order in the CDS archive.
>> 956:   module_paths->sort(ClassLoaderExt::compare_module_path_by_name);
> 
> I think it's better to put this call inside `ClassLoaderExt::extract_jar_files_from_path`

My thinking was since the function may return false at line 953, the entries in the `module_paths` doesn't need to be sorted until before calling `check_paths()`. Anyway, I've made the change you suggested.

> src/hotspot/share/cds/heapShared.cpp line 879:
> 
>> 877: 
>> 878:   ResourceMark rm(THREAD);
>> 879:   if ((strcmp(k->name()->as_C_string(), "jdk/internal/module/ArchivedModuleGraph") == 0) &&
> 
> You can avoid the ResourceMark by
> 
> 
> if (k->name()->equals("jdk/internal/module/ArchivedModuleGraph")

Done.

> src/hotspot/share/cds/heapShared.cpp line 885:
> 
>> 883:     log_info(cds, heap)("Skip initializing ArchivedModuleGraph subgraph: is_using_optimized_module_handling=%s num_module_paths=%d",
>> 884:                         BOOL_TO_STR(CDSConfig::is_using_optimized_module_handling()), ClassLoaderExt::num_module_paths());
>> 885:     return;
> 
> I think we can add a comment like:
> 
> 
> ArchivedModuleGraph was created with a --module-path that's different than the runtime --module-path.
> Thus, it might contain references to modules that do not exist in runtime. We cannot use it.

Added the comment.

> src/hotspot/share/classfile/classLoader.cpp line 582:
> 
>> 580:                                       false /*is_boot_append */, false /* from_class_path_attr */);
>> 581:   if (new_entry != nullptr) {
>> 582:     assert(new_entry->is_jar_file(), "module path entry %s is not a jar file", new_entry->name());
> 
> How do we guarantee that new_entry is never a JAR file? Do we never come here if --module-path points to an exploded directory? A comment would be helpful.

I've added the following comment:
  `// ClassLoaderExt::process_module_table() filters out non-jar entries before calling this function.`

> src/hotspot/share/classfile/classLoaderExt.cpp line 152:
> 
>> 150:   DIR* dirp = os::opendir(path);
>> 151:   if (dirp == nullptr && errno == ENOTDIR && has_jar_suffix(path)) {
>> 152:     module_paths->append(path);
> 
> Does this handle the case where `path` doesn't exist?

If the `path` doesn't exist, `dirp` will be nullptr and it will go to the else case. I think `os::readir` on `nullptr` should return a `nullptr`. To make the code clearer, I've added a `nullptr` check on `dirp` in the else case.

> src/hotspot/share/classfile/classLoaderExt.cpp line 162:
> 
>> 160:         int n = os::snprintf(full_name, full_name_len, "%s%s%s", path, os::file_separator(), file_name);
>> 161:         assert((size_t)n == full_name_len - 1, "Unexpected number of characters in string");
>> 162:         module_paths->append(full_name);
> 
> Can this case be handled: --module-path=dir
> 
> - Dump time :  dir contains only mod1.jar
> - Run time :  dir contains only mod1.jar and mod2.jmod

It should work because the jmod file won't be added to the `module_paths`.

> src/hotspot/share/runtime/arguments.cpp line 347:
> 
>> 345:     }
>> 346:   }
>> 347:   return false;
> 
> Can this be simplified to `return (strcmp(key, MODULE_PROPERTY_PREFIX PATH) == 0)`?

I'm not sure. Is your suggest equivalent to:
  `return (strcmp(key, "jdk.module.path"));`

> src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 1092:
> 
>> 1090:     void resetArchivedStatesForAppClassLoader() {
>> 1091:         setClassPath(null);
>> 1092:         if (!moduleToReader.isEmpty()) moduleToReader.clear();
> 
> Suggestion:
> 
>         if (!moduleToReader.isEmpty()) {
>             moduleToReader.clear();
>         }
> 
> 
> Also, do we need to do the same thing for the platform loader as well?

Added braces.
The `setClassPath(null)` used to be in `ClassLoaders.AppClassLoader`. Based on investigations so far, the clearing of the `moduleToReader` map is required only for `AppClassLoader`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776147825
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776147896
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776147991
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776148021
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776148168
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776148232
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776148308
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1776148461

From henryjen at openjdk.org  Thu Sep 26 01:34:35 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 26 Sep 2024 01:34:35 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
In-Reply-To: <lW5HOrJ8HUyseBJNvQQXYarR0nuulqgLkZ9NAzwIF2M=.f27bfd21-6b77-49d3-a869-39c7f5ce831a@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
 <lW5HOrJ8HUyseBJNvQQXYarR0nuulqgLkZ9NAzwIF2M=.f27bfd21-6b77-49d3-a869-39c7f5ce831a@github.com>
Message-ID: <zSzegoHbW6dFTCEoLZwVr7Z3ibdoGgW5BMjPvldMMEI=.6e90c3c8-1bf0-44f0-af5d-23f0bdd75c36@github.com>

On Wed, 25 Sep 2024 23:49:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
>> 
>> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
>> 
>> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
>> 
>> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
>> 
>> So we make this build in advance, and use a static array for values referred more than once.
>> 
>> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.
>
> test/jdk/tools/jlink/JLink3500Packages.java line 35:
> 
>> 33: /*
>> 34:  * @test
>> 35:  * @summary Make sure that 4000 packages in a uber jar can be linked using jlink.
> 
> Should we mention that the number 3500 or 4000 is an arbitrary large number greater than `ModuleDescriptorBuilder.SET_SIZE_THRESHOLD` to trigger the provider method generation?

The bug reported 3300+, I was planning for 4000 but realized we can only do 3500+ so changed to that later due to the byte code we generated for each export.
The SET_SIZE_THRESHOLD is an arbitrary number. I will add a comment to mention that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776176190

From henryjen at openjdk.org  Thu Sep 26 01:39:35 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 26 Sep 2024 01:39:35 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
In-Reply-To: <lW5HOrJ8HUyseBJNvQQXYarR0nuulqgLkZ9NAzwIF2M=.f27bfd21-6b77-49d3-a869-39c7f5ce831a@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
 <lW5HOrJ8HUyseBJNvQQXYarR0nuulqgLkZ9NAzwIF2M=.f27bfd21-6b77-49d3-a869-39c7f5ce831a@github.com>
Message-ID: <Pas0ii_sGK1WZrNlnmv7-Z4OXgsOSD5ZMidCxB2lMJo=.b36c2245-2e64-4d77-85de-35e8688d3fe1@github.com>

On Thu, 26 Sep 2024 00:05:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
>> 
>> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
>> 
>> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
>> 
>> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
>> 
>> So we make this build in advance, and use a static array for values referred more than once.
>> 
>> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1248:
> 
>> 1246:                             methodName,
>> 1247:                             MethodTypeDesc.of(CD_EXPORTS.arrayType()),
>> 1248:                             ACC_PRIVATE | ACC_FINAL | ACC_STATIC,
> 
> Just curious, why do we mark our split provider methods final? The final flag is only used for hiding.

Thanks for pointing that out, I just follow language convention and did not think of that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776178931

From liach at openjdk.org  Thu Sep 26 01:42:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 01:42:40 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image
In-Reply-To: <Pas0ii_sGK1WZrNlnmv7-Z4OXgsOSD5ZMidCxB2lMJo=.b36c2245-2e64-4d77-85de-35e8688d3fe1@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
 <lW5HOrJ8HUyseBJNvQQXYarR0nuulqgLkZ9NAzwIF2M=.f27bfd21-6b77-49d3-a869-39c7f5ce831a@github.com>
 <Pas0ii_sGK1WZrNlnmv7-Z4OXgsOSD5ZMidCxB2lMJo=.b36c2245-2e64-4d77-85de-35e8688d3fe1@github.com>
Message-ID: <_fSNA-eRztimYhQOl7B2JCWcRBYfZIP9tPFN5TR_DsA=.7d4e9874-654d-4e99-b811-fc3681ff49bd@github.com>

On Thu, 26 Sep 2024 01:36:31 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1248:
>> 
>>> 1246:                             methodName,
>>> 1247:                             MethodTypeDesc.of(CD_EXPORTS.arrayType()),
>>> 1248:                             ACC_PRIVATE | ACC_FINAL | ACC_STATIC,
>> 
>> Just curious, why do we mark our split provider methods final? The final flag is only used for hiding.
>
> Thanks for pointing that out, I just follow language convention and did not think of that.

In language convention, I don't think we declare our private static utility methods as final either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1776180846

From dhanalla at openjdk.org  Thu Sep 26 03:32:36 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 26 Sep 2024 03:32:36 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <MUbrv0RLZ-N7TXm4LqRqsU9QXpADsbe7wt5DuCA5LGQ=.591eea8a-9bd0-4791-9a85-137b3190e877@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <tzwuAXVnDvgziQxJHpZPuxd0oCsGXIO1kb8M4vRUttg=.17d6d31d-8532-4615-9e1b-958bee18e75c@github.com>
 <BM1xZl0lrzbLYOasWiCMvDepPbvM6UvxFudV5b6NThI=.b50b0540-fd6d-4b4b-ad36-6d60310d0eda@github.com>
 <MUbrv0RLZ-N7TXm4LqRqsU9QXpADsbe7wt5DuCA5LGQ=.591eea8a-9bd0-4791-9a85-137b3190e877@github.com>
Message-ID: <ZHx_3M8YsLGqF1hzDmozjdRK_W3vVYxR1qlcw9jm8do=.b4fe7055-0adf-4855-9517-dbe2bcc0c253@github.com>

On Fri, 20 Sep 2024 20:35:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > > Do we have any apps commonly run as a Windows SYSTEM account which expect to attach to other Java apps run by a different Java version? You're suggesting that will have no impact and agreed it would seem really unusual. 8-)
> > 
> > 
> > Good Question @kevinjwalls. We are not aware of any customers using attach api tools with Java application of different versions. In these cases, we recommend upgrading to the latest version.
> 
> It has been a goal to maintain attach compatibility between different versions of the attaching and attached to JVMs. We've fixed bugs in this area in the past. For example, there have been changes that caused old versions of attaching tools like jstack and jcmd to fail when attaching to newer JVMs. We've gone back and fixed these issues in the past. Note in these cases the issue had to do with the protocol used to communicate arguments, not the actual attach itself. I think in the case of this PR we are talking about a failure locate/identify the target JVM.
Thank you @plummercj for sharing your insights. 
Could you please provide some guidance on how we can maintain compatibility?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2375781969

From darcy at openjdk.org  Thu Sep 26 05:03:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 05:03:01 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight" [v2]
In-Reply-To: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
Message-ID: <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>

> Add citation of the second edition of "Hacker's Delight".

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21194/files
  - new: https://git.openjdk.org/jdk/pull/21194/files/6ad81249..09e17743

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21194&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21194&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21194/head:pull/21194

PR: https://git.openjdk.org/jdk/pull/21194

From bpb at openjdk.org  Thu Sep 26 05:27:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 26 Sep 2024 05:27:37 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight" [v2]
In-Reply-To: <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
 <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
Message-ID: <uCdBi-wrlSpcjPTw3z6-Q2vgDQ8OobA4WokndPys1_8=.1af14705-190a-4f7c-8a6a-8873afacdbcc@github.com>

On Thu, 26 Sep 2024 05:03:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add citation of the second edition of "Hacker's Delight".
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21194#pullrequestreview-2330096833

From thartmann at openjdk.org  Thu Sep 26 06:05:49 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 26 Sep 2024 06:05:49 GMT
Subject: Integrated: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <mSjOLfAxtMuxGBiE7eWWhUEKLPAheVOw_btrdeILmLk=.1d52bd14-c611-4d69-98a5-aa137d4fcd04@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

This pull request has now been integrated.

Changeset: 47c10694
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47c10694c66bc131c8a5e1572340415b8daaba08
Stats:     73 lines in 2 files changed: 70 ins; 1 del; 2 mod

8340812: LambdaForm customization via MethodHandle::updateForm is not thread safe

Reviewed-by: liach, shade, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21160

From thartmann at openjdk.org  Thu Sep 26 06:05:47 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 26 Sep 2024 06:05:47 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <ungDDe93EAYB0DDXPbFvKL7Zag0XlmAy90udH6cFa_k=.938ce5ce-62be-4aa3-8d6f-bcd99ec7ad76@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <ungDDe93EAYB0DDXPbFvKL7Zag0XlmAy90udH6cFa_k=.938ce5ce-62be-4aa3-8d6f-bcd99ec7ad76@github.com>
Message-ID: <eiquLY7DKycz743Ra7A79H1AzULc3pQMFThho_Fdr-8=.4a4ee141-bce4-4e05-b15b-538900e6d35a@github.com>

On Wed, 25 Sep 2024 17:23:21 GMT, Abdelhak Zaaim <duke at openjdk.org> wrote:

>> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
>> 
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
>> 
>> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
>> 
>> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
>> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
>> 
>> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
>> 
>> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
>> 
>> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
>> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
>> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
>> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
>> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
>> 
>> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent store...
>
> Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

Thanks for the review @abdelhak-zaaim !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21160#issuecomment-2376009408

From iris at openjdk.org  Thu Sep 26 06:29:34 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 26 Sep 2024 06:29:34 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight" [v2]
In-Reply-To: <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
 <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
Message-ID: <5SwwTSDbQ7Q9pxf3hhFd4V5ySh82-LbS_Y5aRE-3oQM=.5363a80b-0f25-4ac1-a126-8187396b82c6@github.com>

On Thu, 26 Sep 2024 05:03:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add citation of the second edition of "Hacker's Delight".
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21194#pullrequestreview-2330231397

From liach at openjdk.org  Thu Sep 26 06:32:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 06:32:36 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight" [v2]
In-Reply-To: <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
 <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
Message-ID: <og2v4hmaNs9WTTDbEbKh_ejfkylF4M8Nx4_w12KhmXk=.3f867ced-5d02-4556-94cb-dd15b5d391a5@github.com>

On Thu, 26 Sep 2024 05:03:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add citation of the second edition of "Hacker's Delight".
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

The section number reference 7.7 to the Sheep and Goats operation is correct.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21194#pullrequestreview-2330236253

From liach at openjdk.org  Thu Sep 26 06:37:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 06:37:40 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
Message-ID: <4m_ET3E-272OuvewltOrka9AL_eYlFy7d2a4-PCOshM=.20bf8d37-078b-40f9-95f7-6fd3bfb58c3f@github.com>

On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AbstractPoolEntry is broken too

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20773#issuecomment-2376050470

From liach at openjdk.org  Thu Sep 26 06:37:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 06:37:41 GMT
Subject: Integrated: 8339260: Move rarely used constants out of ClassFile
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <PbRVCsqgSmZ7dBoQNt68GGHlqX2e8PLPRtFoaf94Hm4=.7c0a8721-9330-43ec-8ac6-3d80fe796699@github.com>

On Thu, 29 Aug 2024 14:57:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

This pull request has now been integrated.

Changeset: 8c8f0d85
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c8f0d85ce30e45c34d4b096f7f1430cd9e7fd70
Stats:     2458 lines in 37 files changed: 542 ins; 913 del; 1003 mod

8339260: Move rarely used constants out of ClassFile

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20773

From jpai at openjdk.org  Thu Sep 26 06:42:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Sep 2024 06:42:11 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v11]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <fniWHpyWaqa113zVpezK96RX9738kgHwAepJA9Uw4Xo=.be5e5820-5f62-4003-9f73-a87a04cc78f0@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 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
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - ... and 11 more: https://git.openjdk.org/jdk/compare/66f16398...c21c8b32

-------------

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=10
  Stats: 568 lines in 4 files changed: 558 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

PR: https://git.openjdk.org/jdk/pull/2752

From asotona at openjdk.org  Thu Sep 26 08:16:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Sep 2024 08:16:50 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Updated copyright years
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

-------------

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=05
  Stats: 795 lines in 165 files changed: 0 ins; 479 del; 316 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

PR: https://git.openjdk.org/jdk/pull/19826

From eirbjo at openjdk.org  Thu Sep 26 08:53:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Sep 2024 08:53:37 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <ONrGMOYOh2pEjfL_WgTDZy6SzlZPWu6tcdCjSg1MbzU=.2133be3b-0ee2-4353-8e14-7fa28a683958@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <ONrGMOYOh2pEjfL_WgTDZy6SzlZPWu6tcdCjSg1MbzU=.2133be3b-0ee2-4353-8e14-7fa28a683958@github.com>
Message-ID: <BLhWSbruslsPwasNjRwKdTXXao0LGlTUoK-alqddMFM=.d6d5d22b-8acc-4de9-bfd6-49feab3c0074@github.com>

On Tue, 10 Sep 2024 20:09:42 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think the changes look reasonable and make sense. Will need to an internal run as well for a sanity check.

@LanceAndersen Was your internal run successful for this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20905#issuecomment-2376344364

From swen at openjdk.org  Thu Sep 26 10:10:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 26 Sep 2024 10:10:50 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames
Message-ID: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>

1. Construct Frames directly without BitSet
2. Use Frame[] instead of ArrayList
3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.

-------------

Commit messages:
 - bug fix
 - Use Frame[] instead of List<Frame>
 - frame out of BytecodeRange
 - optimize StackMapGenerator::generate

Changes: https://git.openjdk.org/jdk/pull/21183/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21183&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341006
  Stats: 127 lines in 1 file changed: 59 ins; 37 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/21183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21183/head:pull/21183

PR: https://git.openjdk.org/jdk/pull/21183

From jwaters at openjdk.org  Thu Sep 26 10:39:34 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 26 Sep 2024 10:39:34 GMT
Subject: RFR: 8340981: Update citations to "Hacker's Delight" [v2]
In-Reply-To: <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
 <hVfxHl-xrlN4Bx5UPRW5XSpFK91w2krHceOyogXg1Yk=.73df784f-4f17-4204-ac68-43598898fb4b@github.com>
Message-ID: <6BZS8EaPVj3BtI86SMbP8IYOy8dM6io32xwRH5_f18s=.b8365cfc-cf20-4ead-90ec-e11106ca9fcf@github.com>

On Thu, 26 Sep 2024 05:03:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add citation of the second edition of "Hacker's Delight".
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Interesting Pull Request for sure :)

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21194#pullrequestreview-2330812079

From jwaters at openjdk.org  Thu Sep 26 10:43:34 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 26 Sep 2024 10:43:34 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <hwvD_1EGftmYe9CxpZQeoqp3mtvLVbFAn4BIL4bVgaE=.21938e96-a569-426b-b8c5-97024f4f529a@github.com>

On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

jni_md.h seems like a pretty big sledgehammer for something that seems to only be in one file, for just java.desktop. Is this macro planned to be used outside of java.desktop?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2376587585

From kevinw at openjdk.org  Thu Sep 26 10:48:42 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 26 Sep 2024 10:48:42 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
Message-ID: <YGVRXjH6ZuCDowsv79sn424uMHx7WAdFdl8tQhghM5k=.0d2f9da1-8cab-4327-8eb3-1205ceed185e@github.com>

On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
>> 
>> 
>> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
>> 
>> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
>> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
>> 3. Some parts of the code are written in C others in C++.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix missing code

Right, so within a particular environment you can try and have matching JDK versions, but in the world as a whole we do care about different versions being able to attach to each other.  (If JVMs have different temp dirs, they won't find each other and attach.)

Changing the temp dir for SYSTEM processes on Windows will mean they can't be found by a SYSTEM process from a previous JDK version (assuming that SYSTEM processes already have a different temp dir to regular user processes).

That may be a vanishingly small amount of processes out in the world affected, so the incompatibility risk may be small.  But also if there are no processes that benefit, is it worth the complexity of the change.   Maybe we can think of some examples of processes affected.  How would you go about running a Java app in this way, and can we say anything about how common it is?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2376597466

From mbaesken at openjdk.org  Thu Sep 26 11:53:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 26 Sep 2024 11:53:37 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <hwvD_1EGftmYe9CxpZQeoqp3mtvLVbFAn4BIL4bVgaE=.21938e96-a569-426b-b8c5-97024f4f529a@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <hwvD_1EGftmYe9CxpZQeoqp3mtvLVbFAn4BIL4bVgaE=.21938e96-a569-426b-b8c5-97024f4f529a@github.com>
Message-ID: <j7pOVmjxxK1CVYBJzpfVGYTNTH1v0Ee3Gp-Zbu0JQak=.a8262ff2-937c-47ce-a06c-73cf46343601@github.com>

On Thu, 26 Sep 2024 10:41:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> jni_md.h seems like a pretty big sledgehammer for something that seems to only be in one file, for just java.desktop. Is this macro planned to be used outside of java.desktop?

Yes I have a couple (currently 2) more I would like to exclude as well .
The exclusions should work (similar to HS) for the whole  JDK C codebase.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2376722785

From mbaesken at openjdk.org  Thu Sep 26 12:04:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 26 Sep 2024 12:04:37 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <j7pOVmjxxK1CVYBJzpfVGYTNTH1v0Ee3Gp-Zbu0JQak=.a8262ff2-937c-47ce-a06c-73cf46343601@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <hwvD_1EGftmYe9CxpZQeoqp3mtvLVbFAn4BIL4bVgaE=.21938e96-a569-426b-b8c5-97024f4f529a@github.com>
 <j7pOVmjxxK1CVYBJzpfVGYTNTH1v0Ee3Gp-Zbu0JQak=.a8262ff2-937c-47ce-a06c-73cf46343601@github.com>
Message-ID: <uBDB-VUw8-MF8hCBvkHNLEJ8UmBqv6ZgRXya07vR2iM=.6986c899-f0a4-4859-9ee5-a734a30103ce@github.com>

On Thu, 26 Sep 2024 11:51:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The exclusions should work (similar to HS) for the whole JDK C codebase.

Maybe we can offer a separate header ub.hpp next to jni_md.h  that contains the macro/attribute stuff.
Similar to sanitizers/ub.hpp in HS.  This header is then included in the few files were the macro/attributes are needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2376743367

From lancea at openjdk.org  Thu Sep 26 12:29:40 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 26 Sep 2024 12:29:40 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <BLhWSbruslsPwasNjRwKdTXXao0LGlTUoK-alqddMFM=.d6d5d22b-8acc-4de9-bfd6-49feab3c0074@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <ONrGMOYOh2pEjfL_WgTDZy6SzlZPWu6tcdCjSg1MbzU=.2133be3b-0ee2-4353-8e14-7fa28a683958@github.com>
 <BLhWSbruslsPwasNjRwKdTXXao0LGlTUoK-alqddMFM=.d6d5d22b-8acc-4de9-bfd6-49feab3c0074@github.com>
Message-ID: <w6spWccTgX-1rMx-pLBe9FCWoxK0vplMH9JPG0jOhQk=.0320cccf-6fd5-413a-bfef-215d17c8f40b@github.com>

On Thu, 26 Sep 2024 08:50:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> > I think the changes look reasonable and make sense. Will need to an internal run as well for a sanity check.
> 
> @LanceAndersen Was your internal run successful for this change?

Yes I completed this late Tuesday and did not see any issues.

Let's give it till Monday to push so that Jai might also have a chance to review and we are not doing this over the weekend.

I will approve tomorrow

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20905#issuecomment-2376813470

From viktor.klang at oracle.com  Thu Sep 26 13:02:13 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 26 Sep 2024 13:02:13 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <44a9c1cfd7586a141bc2804b43b89c9bc0fc7e73@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
 <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>
 <MW4PR10MB57748593DAC464069BA2B177FF912@MW4PR10MB5774.namprd10.prod.outlook.com>
 <3383cde8fe4c34291f393f9a6389bd6c34879561@anthonyv.be>
 <MW4PR10MB5774B57719ED570F421A572DFF982@MW4PR10MB5774.namprd10.prod.outlook.com>
 <339118ae3a40654420b19a4be45dfb877de5176c@anthonyv.be>
 <MW4PR10MB57741EFFCC6EB4A77A8ACB21FF642@MW4PR10MB5774.namprd10.prod.outlook.com>
 <4d26031ad7ad2773197ddc4ff2f32d1e93fe1ae7@anthonyv.be>
 <MW4PR10MB57741DBB8EC8562AD2224B1EFF632@MW4PR10MB5774.namprd10.prod.outlook.com>
 <46bc86380b39b14b20d3d1e589015594b15c1189@anthonyv.be>
 <MW4PR10MB577469B9A299BC7EC6D62779FF6F2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <44a9c1cfd7586a141bc2804b43b89c9bc0fc7e73@anthonyv.be>
Message-ID: <MW4PR10MB5774583FE74B0D9F05AB1375FF6A2@MW4PR10MB5774.namprd10.prod.outlook.com>

Having thought about it some more and this type of information has more of a tutorial-nature to it.

I'm going to try to find some time to focus on something like that ahead of Java 24 and hopefully create something to this effect.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Anthony Vanelverdinghe <dev at anthonyv.be>
Sent: Monday, 23 September 2024 21:04
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback

Hi Viktor

Thanks for bearing with me.

> [...] are you suggesting that we add a section in the Gatherer (and Collector) in the form of "Implementor Notes" that are a bit more high-level than the specification?

Yes, exactly, explicitly mentioning reusability (I actually read through the Javadoc at the time, but didn't connect the dots) and providing guidance/recommending alternatives for use cases where one might be tempted to write a non-reusable Gatherer (I think these use cases can be summarized as: combining a Stream with another Stream, where both Streams might be infinite).

Kind regards, Anthony

September 23, 2024 at 5:19 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> Hi Anthony,
>
> >The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.
>
> Even if this is well-intentioned, my experience tells me that this feedback will not materialize, and trying to provoke conformance at runtime will have a noticeable performance impact not encumbering other intermediate operations, especially for processing the bulk majority of streams (which tend to be less than 10 elements in size).
>
> >This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".
>
> Adding clarifications to the Javadoc may be the most balanced path forward, in doing so we're talking updating the documentation for both Gatherer and Collector.
>
> >Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it?
>
> No, that would be "moving the goalposts" i.e. making Gatherers specified more loosely. Developers will write the code that they write, but if something isn't behaving as expected, it is important to know which side to debug?the library or the user code.
>
> > I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers.
>
> The ability for developers to implement interfaces (knowingly or unknowingly) in non-spec-conforming ways aside, are you suggesting that we add a section in the Gatherer (and Collector) in the form of "Implementor Notes" that are a bit more high-level than the specification?
>
> Cheers,
>
> ?
>
> **Viktor Klang**
> Software Architect, Java Platform Group
>
> Oracle
>
> ????????????????????????????????????????????????????????????????
>
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Thursday, 19 September 2024 20:57
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
>
> Hi Viktor
>
> > Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather).
>
> The idea is to collect feedback, to see how many people report their Gatherers being broken (i.e. their Gatherers being non-compliant without realizing it), so enforcing it in `Stream::gather` is sufficient for this purpose.
>
> This hasn't come up before because it requires people (a) to read the Javadoc, (b) to connect the dots and conclude "thus, a Gatherer must be reusable", and (c) to be willing to invest their time in asking the question, rather than moving on since their Gatherers "just work".
>
> > java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?
>
> For `Stream` the package Javadoc has statements like "No storage. A stream is not a data structure" and "Possibly unbounded.", which is sufficient rationale to me.
>
> For `Collector`, unless I'm missing something, it does not actually specify that it must be reusable, so it does not have to provide a rationale for it either. Even if I did miss something and reusability is implied from the specification: the question would likely never come up, because a Collector will in practice always be reusable anyway (read: I can't readily think of a sensible non-reusable Collector). This is unlike Gatherer, where some obvious use cases such as `concat` and `zip` exist and people like me wonder why such use cases are, apparently needlessly, prohibited by the Gatherer specification.
>
> > Think of it more like increasing the odds that users are given spec-conformant Gatherers.
>
> Not sure I understand this argument? I'd argue that increasing those odds would be done by allowing an additional category of Gatherers, not by prohibiting it? I've written a `concat` Gatherer being blissfully unaware that it was not compliant, others have written non-reusable Gatherers as well: they exist and things like `concat` and `zip` are natural/intuitive use cases for Gatherers. Gunnar wrote a blog post [https://urldefense.com/v3/__https://www.morling.dev/blog/zipping-gatherer/__;!!ACWV5N9M2RV99hQ!KmRJAZ0OMfv5XrDKYFVNTJyVWBah899OR9tdZKUHJB928SXc6VEdT4ni1AHI_lGezKchV9kYO04XUdClsg$ ] about his `zip` Gatherer saying "Java 22 [...] promises to improve the situation here." and none of his readers pointed out that his Gatherer is not compliant either (nor complained that his Gatherer is not reusable).
>
> Kind regards, Anthony
>
> September 19, 2024 at 11:30 AM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > Hi Anthony,
>
> >
>
> > Bear with me for a moment,
>
> >
>
> > in the same vein as there's nothing which *enforces* equals(?) or hashCode() to be conformant to their specs, or any interface-implementation for that matter, I don't see how we could make any stronger enforcement of Gatherers.
>
> >
>
> > >My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
>
> >
>
> > Alas, there's no place where this could be enforced, users could have their own implementations of Stream (so cannot be enforced in Stream::gather). Ultimately, it all boils down to specification?if an equals(?)-method implementation leads to surprising behavior when used with a collection, one typically needs to first ensure that the equals(?)-method conforms to its expected specification before one can presume that the collection has a bug.
>
> >
>
> > For the "just work"?scenario, one can only make claims about things which have been proven. So in this case, what tests have passed for the implementation in question?
>
> >
>
> > >Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction.
>
> > java.util.stream.Stream does not explain the rationale for why it is single-use, Collector does not explain why they are reusable, why would Gatherers be held to a different standard?
>
> >
>
> > > "protecting the users from being given non-reusable Gatherers"
>
> > Think of it more like increasing the odds that users are given spec-conformant Gatherers.
>
> >
>
> > Cheers,
>
> >
>
> > ?
>
> >
>
> > **Viktor Klang**
>
> > Software Architect, Java Platform Group
>
> >
>
> > Oracle
>
> >
>
> > ????????????????????????????????????????????????????????????????
>
> >
>
> > **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
>
> > **Sent:** Wednesday, 18 September 2024 18:27
>
> > **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> > **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
> >
>
> >
>
> > Hi Viktor
>
> >
>
> > Let me start with a question: is the requirement (a) "a Gatherer SHOULD be reusable", or (b) "a Gatherer MUST be reusable"?
>
> >
>
> > As of today the specification says (b), whereas the implementation matches (a).
>
> >
>
> > In case of (a), I propose to align the specification to allow for compliant, non-reusable Gatherers.
>
> >
>
> > In case of (b), I propose to align the implementation to enforce compliance. Something like:
>
> >
>
> > (1) invoke `initializer()` twice, giving `i1` and `i2`. Discard `i1` and invoke `i2` twice, giving `state1` and `state2`.
>
> >
>
> > (2) invoke `finisher()` twice, giving `f1` and `f2`. Discard `f1` and invoke `f2` twice, the first time with `state1` and a dummy Downstream, the second time with the actual final state, i.e. `state2` after all elements were integrated, and the actual Downstream.
>
> >
>
> > Then backport this change to JDK 23 & 22 and/or do another round of preview in JDK 24.
>
> >
>
> > I'm confident that enforcing compliance would result in significant amounts of feedback questioning the requirement.
>
> >
>
> > My belief is that the subject of reusability hasn't come up before because non-reusable Gatherers "just work": as long as instances of such Gatherers are not reused, they don't lead to unexpected results or observable differences in behavior. And so people have been implementing non-reusable Gatherers such as `concat` and `zip` without realizing they aren't compliant. Or maybe they did realize it, but didn't see the downside of being non-compliant.
>
> >
>
> > Which brings me to my next point: in case of (b), the Javadoc and/or JEP should explain the rationale. Even to me it still seems like a needless restriction. You say:
>
> >
>
> > > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
>
> >
>
> > so I'd guess the rationale is "protecting the users from being given non-reusable Gatherers".
>
> >
>
> > However, I can't readily think of a situation where this would be essential.
>
> >
>
> > If a user creates a Gatherer by invoking a factory method, the factory method can specify whether its result is reusable.
>
> >
>
> > And if a user is given a Gatherer as a method argument, and they need the Gatherer to be reusable, they could change the parameter to a `Supplier<Gatherer>` instead.
>
> >
>
> > > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
>
> >
>
> > >
>
> >
>
> > > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
>
> >
>
> > We agree, just that I'd provide 2 factory methods, `concat(Stream<T>)` (non-reusable) and `append(List<T>)` (reusable), whereas you'd provide a 2-in-1 `concat(Supplier<Stream<T>>)`.
>
> >
>
> > Kind regards, Anthony
>
> >
>
> > September 12, 2024 at 11:55 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > >
>
> >
>
> > > Hi Anthony
>
> >
>
> > >
>
> >
>
> > > Great questions! I had typed up a long response when my email client decided the email was too large, crashed, and deleted my draft, so I'll try to recreate what I wrote from memory.
>
> >
>
> > >
>
> >
>
> > > >While I understand that most Gatherers will be reusable, and that it's a desirable characteristic, surely there will also be non-reusable Gatherers?
>
> >
>
> > >
>
> >
>
> > > To me, this is governed by the following parts of the Gatherer specification https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html :
>
> >
>
> > >
>
> >
>
> > > "Each invocation of initializer() https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#initializer() ,integrator()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#integrator() ,combiner()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#combiner() , and finisher()https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.html#finisher()  must return a semantically identical result."
>
> >
>
> > >
>
> >
>
> > > and
>
> >
>
> > >
>
> >
>
> > > "Implementations of Gatherer must not capture, retain, or expose to other threads, the references to the state instance, or the downstreamGatherer.Downstreamhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html PREVIEWhttps://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/stream/Gatherer.Downstream.html#preview-java.util.stream.Gatherer.Downstream  for longer than the invocation duration of the method which they are passed to."
>
> >
>
> > >
>
> >
>
> > > And I think the worst of all worlds would be a scenario where you, as a user, are given a Gatherer<X,Y,Z> and you have no idea whether you can re-use it or not.
>
> >
>
> > >
>
> >
>
> > > For Stream, the assumption is that they are NOT reusable at all.
>
> >
>
> > > For Gatherer, I think the only reasonable assumption is that they are reusable.
>
> >
>
> > >
>
> >
>
> > > >In particular, any Gatherer that is the result of a factory method with a `Stream<T>` parameter which supports infinite Streams, will be non-reusable, won't it?
>
> >
>
> > >
>
> >
>
> > > Not necessarily, if the factory method **consumes** the Stream and creates a stable result which is reusable, then the resulting Gatherer is reusable.
>
> >
>
> > >
>
> >
>
> > > >In a previous response you proposed using `Gatherer concat(Supplier<Stream<T>>)` instead, but then I'd just pass `() -> aStream`, wonder why the parameter isn't just a `Stream<T>`, and the Gatherer would still not be reusable.
>
> >
>
> > >
>
> >
>
> > > There's a very important, to me, difference between the two. In the Stream-case, there exists 0 reusable usages. For the Supplier<Stream>-case the implementation does not restrict re-usability, but rather it is up to the caller to actively opt-out of reusability (which could of course also be declared to be undefined behavior of the implementor of said Gatherer). Local non-reusability decided by the caller > Global non-reusability decided by the callee.
>
> >
>
> > >
>
> >
>
> > > >As another example, take Gunnar Morling's zip Gatherers:
>
> >
>
> > >
>
> >
>
> > > I don't see how Gatherers like this could be made reusable, or why that would even be desirable.
>
> >
>
> > >
>
> >
>
> > > Having been R&D-ing in the Stream-space more than a decade, I'm convinced that there's no universally safe way to implement `zip` for push-style stream designs. I'm happy to be proven wrong though, as that would open up some interesting possibilities for things like Stream::iterator() and Stream:spliterator().
>
> >
>
> > >
>
> >
>
> > > >My use case was about a pipeline where the concatenation comes somewhere in the middle of the pipeline.
>
> >
>
> > >
>
> >
>
> > > My apologies, I misunderstood. To me, the operation you describe is called `inject`.
>
> >
>
> > > Given a stable (reusable) source of elements you can definitely implement Gatherers which do before, during, or after-injections of elements to a stream.
>
> >
>
> > >
>
> >
>
> > > Thanks again for the great questions and conversation, it's valuable!
>
> >
>
> > > Cheers,
>
> >
>
> > >
>
> >
>
> > > ?
>
> >
>
> > >
>
> >
>
> > > **Viktor Klang**
>
> >
>
> > > Software Architect, Java Platform Group
>
> >
>
> > >
>
> >
>
> > > Oracle
>
> >
>
> > >
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240926/f5b067a7/attachment-0001.htm>

From rotanolexandr842 at gmail.com  Thu Sep 26 13:07:59 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 26 Sep 2024 16:07:59 +0300
Subject: Range API
In-Reply-To: <5320CD47-A9EB-44BE-994B-F296FC281D3A@cbfiddle.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
 <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
 <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>
 <5320CD47-A9EB-44BE-994B-F296FC281D3A@cbfiddle.com>
Message-ID: <CAL5bRt9zu_WtHUi-0J2L5LThpWfCaGWCrd5cxLHNkJJ52uHHxA@mail.gmail.com>

Researching the of deriving some iterable representations from ranges, and
I am not here with the good news.

Unlike range algebra and boolean operations, which generalize
extremely well, iterability of ranges... Well, it's safe to say it
doesn't generalize at all. Analyzing key features people expect iterable
ranges to have, I ended up concluding there are basically two groups / two
use cases for them. First is plain and simple, arguably the most popular
one: iterating over a range of integer numbers, i.e. `for (i : Range.of(1,
10))`. Another use case is for more complex iterations over ranges of
reference types, most commonly dates/time.

There are two groups of values by their nature: discrete and continuous.
Most of the types belong to the second group, as there is no direct
increment AND decrement for them (we will omit hardware limitations for
simplicity), such as floating point values. What is the increment of 1,3?
1.31 or 1.30000000001, or maybe something even more unreadable? On the
other hand, the increment of LocalDate in context of range iteration that
represents today is rather obvious - it is tomorrow.

There is a pretty limited number of discrete types in jdk. Dates, whole
numbers and basically that's it. The discrete types that are not present in
jdk can be really various. For example, users can define a comparable
type "F1Team" and compare them based on their position in the last race.
There, increment would most likely be the next team in rating. There are
many domain-specific cases like this.

This is where the problem comes from. If the user would always have to pass
a comparator to create a range, it would be consistent to make the user
define increment/decrement as well. But we don't want users to pass a
comparator if the type is already comparable. Similarly, we don't want
users to define increment/decrement if there is already one in the
language! I think defining increments for dates (say LocalDate.plusDays(1))
would be acceptable, even defining increments for floats in context of
ranges might be acceptable, but making people define increments for
integers is, in my opinion, completely not. Besides performance impact,
this is a terrible user experience.

There are a few solutions to this:
1) Define ton of overrides for factory methods and specialized types for
this (uhh, sounds awful)
2) Introduce new interface, say Discrete<T>, that defines T increment()
(and possible T decrement()) methods. From now on, there are 2 branches:
2.1) Leave things as is, allow users to define incrementation logic for
their types, but don't touch integers and other built-ins.I see this option
as extremely inconsistent and not solving the main issue, which is
iterability of integers.
2.2) Retrofit (scary) existing types to implement this interface. This
should not have any compatibility nor security implications, but still
sneaking into java.lang every time we need some new API to be more
user-friendly is obviously not a way to go. This basically comes down to a
question about how deep we want to integrate ranges into language, and is
range  generalization even worth the invasion into the core of
language (imo yes).
3) Leave things as they are, just let users derive iterables using
something like range.asIterableWithStep(IncremetStartegy increment). I
think this would make an API too narrow as no one will use it for routine
tasks the same way people do in Rust, Kotlin and other languages.

I would love to hear community opinion on this matter. Which option is the
most preferable, maybe some compromise between a few of them, or maybe
there is a better way to go that I didn't mention here?

Best regards

On Tue, Sep 24, 2024 at 5:11?PM Alan Snyder <javalists at cbfiddle.com> wrote:

> I have another example: I have a datatype that represents a region of an
> audio track, for example, one tune in a medley of tunes. I allow the region
> to
> specify both a start and end time, but the end time is optional (and
> mostly not used). When the end time is not specified, the region ends at
> the start of the next region, or at
> the end of the track if there is no next region. The latter case is useful
> because the exact track length may not be known. The optionality of the end
> time
> is not represented in the type system.
>
> Having said that, I?m not sure that a general abstract interface would be
> useful for this example.
>
> On Sep 24, 2024, at 2:13?AM, Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
> As part of the redesigning  process , I am researching whether or not
> there are use cases that require asserting that the range is exactly
> half-bounded. This is important because I plan to switch to
> BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime
> checks: Here is what I gathered for now.
>
>
>    - *Date/Time Handling (Historical or Forecast Data)*: When dealing
>    with events that started at a specific time but have no known end (e.g.,
>    open-ended employment contracts or ongoing subscriptions)
>    - *Stream Processing (Real-time Event Streams)*: In real-time systems,
>    you might process data that has a start time but no defined end, such as
>    monitoring a live video feed or logging system. The range is bounded at the
>    start and unbounded at the end as more data will continuously arrive.
>    - *Data Pagination (Fetch Until Condition)*: When implementing
>    pagination, sometimes you might want to fetch items starting from a
>    specific index up to an unbounded limit (e.g., fetching all items after a
>    certain point until memory runs out or a condition is met).
>    - *Auditing and Monitoring*: In systems where audit trails or logging
>    data should capture all events after a certain point (bounded start) with
>    no foreseeable end (unbounded end), such as monitoring changes to records
>    in a database starting from a fixed timestamp.
>    - *Scientific or Statistical Ranges*: When modeling physical systems
>    or statistical ranges, you might want to capture measurements that begin at
>    a known threshold but theoretically have no upper or lower bound. For
>    example, recording temperature data starting at absolute zero and
>    increasing without any known upper limit.
>    - *Inventory or Resource Allocation*: Resource allocation policies,
>    such as those for virtual machines, may be based on known minimum
>    allocation thresholds but have flexible or unbounded resource caps,
>    depending on availability.
>
>    I am writing to ask whether anyone who worked with such systems could
>    confirm/deny that those are real use cases. If so, would it be satisfying
>    enough to assert one-way unboundness with instanceof checks, i.e. range
>    instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange).
>    Would appreciate any feedback.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240926/c424b197/attachment.htm>

From brian.goetz at oracle.com  Thu Sep 26 13:30:11 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 26 Sep 2024 09:30:11 -0400
Subject: Range API
In-Reply-To: <CAL5bRt9zu_WtHUi-0J2L5LThpWfCaGWCrd5cxLHNkJJ52uHHxA@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
 <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
 <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>
 <5320CD47-A9EB-44BE-994B-F296FC281D3A@cbfiddle.com>
 <CAL5bRt9zu_WtHUi-0J2L5LThpWfCaGWCrd5cxLHNkJJ52uHHxA@mail.gmail.com>
Message-ID: <f8fda70c-9eb5-4cdc-beb7-04a4c83616b8@oracle.com>

Sorry for the not-good news, but I'm not too surprised.? Computational 
domains like "32 bit integers" seem like they should have a lot in 
common with algebraic structures like groups and rings, but when you 
start poking at them, the compromises we make to fit them into hardware 
registers start to bite.? (And let's not get started on floating 
point...) Lots of research into numeric towers in various languages, or 
capturing fundamental properties in type classes like Haskell's `Eq` and 
`Ord`, offers plenty of compromise to go with its promise.

I think a big part of what you are running into is that you've started 
with a _concept_ (a deceptively simple one, at that), rather than 
_requirements_.? And it is the open-endedness of this concept (discrete 
vs continuous, bounded vs half-open, including endpoints or not, etc) 
that resists abstraction.? Plus, without clear requirements, you will be 
subject to an endless barrage of "what about my pet use case" (e.g., 
"what about the numbers zero to ten, advancing by two").? Meanwhile, 
domain-specific libraries such as java.time will invent their own 
domain-specific answers, like Interval.

Rather than starting from the algebraic properties, perhaps start from 
the other end: what are the use cases where the lack of a range 
abstraction is problematic.? I get that

 ??? for (int i=0; i<100; i++) { ... }

is uglier and less abstract than

 ??? for (int i : Range.of(0, 100)) { ... }

but I also don't sense people beating down the doors for that (even if 
the language had range literals, like `0..<100`).

Where I do see people having trouble is that many range computations are 
error prone.? For example, `String::indexOf` returns the starting index 
of a match; if you want to actually iterate over the characters of such 
a match, you have to do something like

 ??? for (int j=index; j<index+target.length(); j++)

and you are at risk for fencepost errors when recreating the range.? 
Whereas an indexOf method (under a more suitable name) that returned a 
range, would be more amenable to downstream processing.? Similarly, I 
see errors in API usage because sometimes we specify range by (start, 
end) and sometimes by (start, length), and since both are ints, we get 
no type checking when you pass the wrong kinds of ints to such a method.

But, the mere existence of a Range type would do little to help String, 
Arrays, and other range-happy APIs, because we would have to update them 
to include new overloads that dispense and consume ranges.? So that's a 
big project.

Still, I think investigating use cases involving libraries that work 
intensively with ranges like this would likely yield useful information 
for what a Range type would want to provide.

HTH,
-Brian






On 9/26/2024 9:07 AM, Olexandr Rotan wrote:
> Researching the of deriving some iterable representations from ranges, 
> and I am not here with the good news.
>
> Unlike range algebra and boolean operations, which generalize 
> extremely?well, iterability of ranges... Well, it's safe to say it 
> doesn't?generalize at all. Analyzing key features people expect 
> iterable ranges to have, I ended up concluding there are basically two 
> groups / two use cases for them. First is plain and simple, arguably 
> the most popular one: iterating over a range of integer numbers, i.e. 
> `for (i : Range.of(1, 10))`. Another use case is for more complex 
> iterations over ranges of reference types, most commonly dates/time.
>
> There are two groups of values by their nature: discrete and 
> continuous. Most of the types belong to the second group, as there is 
> no direct increment AND decrement for them (we will omit hardware 
> limitations for simplicity), such as floating point values. What is 
> the increment of 1,3? 1.31 or 1.30000000001, or maybe something even 
> more unreadable? On the other hand, the increment of LocalDate in 
> context?of range iteration that represents today is rather obvious - 
> it is tomorrow.
>
> There is a pretty limited number of discrete types in jdk. Dates, 
> whole numbers and basically that's?it. The discrete types that are not 
> present in jdk can be really various. For example, users can define a 
> comparable type?"F1Team" and compare them based on their position in 
> the last race. There, increment would most likely be the next team in 
> rating. There are many domain-specific cases like this.
>
> This is where the problem comes from. If the user would always have to 
> pass a comparator to create a range, it would be consistent to make 
> the user define increment/decrement as well. But we don't?want users 
> to pass a comparator if the type is already comparable. Similarly, we 
> don't?want users to define increment/decrement if there is already one 
> in the language! I think defining increments for dates (say 
> LocalDate.plusDays(1)) would be acceptable, even?defining?increments 
> for floats in context of ranges might be acceptable, but making people 
> define increments for integers is, in my opinion, completely not. 
> Besides performance impact, this is a terrible user experience.
>
> There are a few solutions to this:
> 1) Define ton of overrides for factory methods and specialized types 
> for this (uhh, sounds awful)
> 2) Introduce new interface, say Discrete<T>, that defines T 
> increment() (and possible T decrement()) methods. From now on, there 
> are 2 branches:
> 2.1) Leave things as is, allow users to define incrementation logic 
> for their?types, but don't touch integers and other built-ins.I see 
> this option as extremely?inconsistent and not solving the main issue, 
> which is iterability of integers.
> 2.2) Retrofit (scary) existing types to implement this interface. This 
> should not have any compatibility nor security implications, but still 
> sneaking into java.lang every time we need some new API to be more 
> user-friendly is obviously not a way to go. This basically comes down 
> to a question about how deep we want to integrate ranges into 
> language, and is range generalization even worth the invasion into the 
> core of language?(imo yes).
> 3) Leave things as they are, just let users derive iterables using 
> something like range.asIterableWithStep(IncremetStartegy increment). I 
> think this would make an API too narrow as no one will use it for 
> routine tasks the same way people do in Rust, Kotlin and other languages.
>
> I would love to hear community opinion on this matter. Which option is 
> the most preferable, maybe some compromise between a few of them, or 
> maybe there is a better?way to go that I didn't?mention here?
>
> Best regards
>
> On Tue, Sep 24, 2024 at 5:11?PM Alan Snyder <javalists at cbfiddle.com> 
> wrote:
>
>     I have another example: I have a datatype that represents a region
>     of an audio track, for example, one tune in a medley of tunes. I
>     allow the region to
>     specify both a start and end time, but the end time is optional
>     (and mostly not used). When the end time is not specified, the
>     region ends at the start of the next region, or at
>     the end of the track if there is no next region. The latter case
>     is useful because the exact track length may not be known. The
>     optionality of the end time
>     is not represented in the type system.
>
>     Having said that, I?m not sure that a general abstract interface
>     would be useful for this example.
>
>>     On Sep 24, 2024, at 2:13?AM, Olexandr Rotan
>>     <rotanolexandr842 at gmail.com> wrote:
>>
>>     As part of the redesigning? process , I am researching?whether?or
>>     not there are use cases that require asserting that the range is
>>     exactly half-bounded. This is important because I plan to switch
>>     to BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags
>>     and runtime checks: Here is what I gathered for now.
>>
>>       * *Date/Time Handling (Historical or Forecast Data)*: When
>>         dealing with events that started at a specific time but have
>>         no known end (e.g., open-ended employment contracts or
>>         ongoing subscriptions)
>>       * *Stream Processing (Real-time Event Streams)*: In real-time
>>         systems, you might process data that has a start time but no
>>         defined end, such as monitoring a live video feed or logging
>>         system. The range is bounded at the start and unbounded at
>>         the end as more data will continuously arrive.
>>       * *Data Pagination (Fetch Until Condition)*: When implementing
>>         pagination, sometimes you might want to fetch items starting
>>         from a specific index up to an unbounded limit (e.g.,
>>         fetching all items after a certain point until memory runs
>>         out or a condition is met).
>>       * *Auditing and Monitoring*: In systems where audit trails or
>>         logging data should capture all events after a certain point
>>         (bounded start) with no foreseeable end (unbounded end), such
>>         as monitoring changes to records in a database starting from
>>         a fixed timestamp.
>>       * *Scientific or Statistical Ranges*: When modeling physical
>>         systems or statistical ranges, you might want to capture
>>         measurements that begin at a known threshold but
>>         theoretically have no upper or lower bound. For example,
>>         recording temperature data starting at absolute zero and
>>         increasing without any known upper limit.
>>       * *Inventory or Resource Allocation*: Resource allocation
>>         policies, such as those for virtual machines, may be based on
>>         known minimum allocation thresholds but have flexible or
>>         unbounded resource caps, depending on availability.
>>
>>         I am writing to ask whether anyone who worked with such
>>         systems could confirm/deny that those are real use cases. If
>>         so, would it be satisfying enough to assert one-way
>>         unboundness with instanceof checks, i.e. range instanceof
>>         UnboundedEndRange && !(range instanceof UnboundedStartRange).
>>         Would appreciate any feedback.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240926/a78070c3/attachment-0001.htm>

From duke at openjdk.org  Thu Sep 26 13:35:08 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 26 Sep 2024 13:35:08 GMT
Subject: RFR: 8341028: Do not use lambdas or method refs for verifyConstantPool
Message-ID: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>

Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a `Runnable`, which is consumed by a `Consumer<Runnable>` (instantiated within a loop) which runs the task inside if a `try`/`catch`. We can eliminate a number of lambdas and method references, plus some allocation pressure, in this code by simplifying it so that the `switch` is itself run directly within the `try`/`catch`.

-------------

Commit messages:
 - 8341028: Do not use lambdas or method refs for verifyConstantPool

Changes: https://git.openjdk.org/jdk/pull/21209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341028
  Stats: 70 lines in 1 file changed: 29 ins; 33 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21209/head:pull/21209

PR: https://git.openjdk.org/jdk/pull/21209

From liach at openjdk.org  Thu Sep 26 13:44:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 13:44:36 GMT
Subject: RFR: 8341028: Do not use lambdas or method refs for
 verifyConstantPool
In-Reply-To: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
References: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
Message-ID: <ddIk5iRoaxp6SbaVUABbCR3PiRZGuPKro9A_2WdSHCg=.82555284-45ab-4e1f-a315-238b931d3462@github.com>

On Thu, 26 Sep 2024 13:30:07 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a `Runnable`, which is consumed by a `Consumer<Runnable>` (instantiated within a loop) which runs the task inside if a `try`/`catch`. We can eliminate a number of lambdas and method references, plus some allocation pressure, in this code by simplifying it so that the `switch` is itself run directly within the `try`/`catch`.

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 99:

> 97:                         imre.owner().asSymbol();
> 98:                         imre.typeSymbol();
> 99:                         verifyMethodName(imre.name().stringValue());

With the new try-catch, say if all lines end up erroneous, we will only get 1 error instead of 3 like before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21209#discussion_r1777104036

From redestad at openjdk.org  Thu Sep 26 13:45:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 26 Sep 2024 13:45:42 GMT
Subject: RFR: 8340571: Outline code from the loop in ZipFile.Source.initCen
 [v3]
In-Reply-To: <ozgDEVmdCKft5dXO45QjfX3ZIKrS-_owasQbeyO8Gbk=.792b27ce-991d-4605-bdd4-5fa708929106@github.com>
References: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
 <ozgDEVmdCKft5dXO45QjfX3ZIKrS-_owasQbeyO8Gbk=.792b27ce-991d-4605-bdd4-5fa708929106@github.com>
Message-ID: <RLRn_rlOwPpUZjYYTMBzsYPTsV5Uv62HgHIgqaJVLmQ=.02e812d1-6f3e-4af4-9819-7f18d581570c@github.com>

On Wed, 25 Sep 2024 13:43:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic as possible into the per-entry method processor. This inner method will be called often and JIT optimized earlier in the bootstrap sequence.
>> 
>> Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both my M1 macbook and my x64 wokstation, while we also improve on relevant throughput microbenchmarks:
>> 
>> 
>> Name               (size) Cnt       Base      Error        Test      Error  Unit  Change
>> openCloseZipFile      512  15  61372.449 ? 1197.432   58081.423 ? 1751.988 ns/op   1.06x (p = 0.000*)
>> openCloseZipFile     1024  15 117953.727 ? 3202.274  112548.875 ? 5126.665 ns/op   1.05x (p = 0.001*)
>> openCloseZipFilex2    512  15  62141.795 ?  674.121   60520.017 ? 2438.346 ns/op   1.03x (p = 0.017 )
>> openCloseZipFilex2   1024  15 117959.071 ? 1528.426  111773.937 ? 1604.412 ns/op   1.06x (p = 0.000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Worth trying out. Your approach seem to improve on throughput, while my main goal has been improving on startup/warmup with throughput wins as a side effect. Let's get #20905 reviewed and integrated, sync up then I'll play around with some variants here. I'll put this back as draft in the interim.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21133#issuecomment-2374984794

From duke at openjdk.org  Thu Sep 26 13:49:11 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 26 Sep 2024 13:49:11 GMT
Subject: RFR: 8341028: Do not use lambdas or method refs for
 verifyConstantPool [v2]
In-Reply-To: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
References: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
Message-ID: <AlSmUg1luerd8-_Ak0jzkz5XzJQi_zT8FvNWCaRNyYk=.a052ca6d-2f63-495e-96d8-626315ddfa07@github.com>

> Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a `Runnable`, which is consumed by a `Consumer<Runnable>` (instantiated within a loop) which runs the task inside if a `try`/`catch`. We can eliminate a number of lambdas and method references, plus some allocation pressure, in this code by simplifying it so that the `switch` is itself run directly within the `try`/`catch`.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Make sure that we record every error instead of stopping at the first error in a particular CPE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21209/files
  - new: https://git.openjdk.org/jdk/pull/21209/files/15b03b47..f1572865

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21209&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21209&range=00-01

  Stats: 40 lines in 1 file changed: 32 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21209/head:pull/21209

PR: https://git.openjdk.org/jdk/pull/21209

From duke at openjdk.org  Thu Sep 26 13:49:11 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 26 Sep 2024 13:49:11 GMT
Subject: RFR: 8341028: Do not use lambdas or method refs for
 verifyConstantPool [v2]
In-Reply-To: <ddIk5iRoaxp6SbaVUABbCR3PiRZGuPKro9A_2WdSHCg=.82555284-45ab-4e1f-a315-238b931d3462@github.com>
References: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
 <ddIk5iRoaxp6SbaVUABbCR3PiRZGuPKro9A_2WdSHCg=.82555284-45ab-4e1f-a315-238b931d3462@github.com>
Message-ID: <uAARnLLK4raKMzZ5cP52-lJKdR-t7zG3xVWBVgCrcdY=.c57f6fb4-e7e0-42bb-9cb4-80de8d213784@github.com>

On Thu, 26 Sep 2024 13:41:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure that we record every error instead of stopping at the first error in a particular CPE
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 99:
> 
>> 97:                         imre.owner().asSymbol();
>> 98:                         imre.typeSymbol();
>> 99:                         verifyMethodName(imre.name().stringValue());
> 
> With the new try-catch, say if all lines end up erroneous, we will only get 1 error instead of 3 like before.

Fair point; given that there's only a couple of those though, maybe I could give them their own `try`/`catch`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21209#discussion_r1777109625

From liach at openjdk.org  Thu Sep 26 14:06:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Sep 2024 14:06:41 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
Message-ID: <v_TJ9AvGQXpaR3IgjRk_ePx_vx9gpEkD6E-Gjcma-1c=.16844e0e-5445-4ce9-87ba-0ebc0389ea26@github.com>

On Thu, 26 Sep 2024 08:16:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Updated copyright years
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
>  - Merge branch 'master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
>    #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

All `@since` tags in the `java.lang.classfile` directory are `@since 24`.

@nizarbenalla Is it possible to enable the since checker in java.lang.classfile and its nested packages.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2331373411

From jwaters at openjdk.org  Thu Sep 26 14:27:34 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 26 Sep 2024 14:27:34 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <H2RaDUegzFunqkJNfBjwUVqDfI0tqmJ2LL9qK1a9g-0=.0daa4fa3-f0a4-475b-b2e4-9d8f674f3ca7@github.com>

On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21184#pullrequestreview-2331451920

From jwaters at openjdk.org  Thu Sep 26 14:27:35 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 26 Sep 2024 14:27:35 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <j7pOVmjxxK1CVYBJzpfVGYTNTH1v0Ee3Gp-Zbu0JQak=.a8262ff2-937c-47ce-a06c-73cf46343601@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <hwvD_1EGftmYe9CxpZQeoqp3mtvLVbFAn4BIL4bVgaE=.21938e96-a569-426b-b8c5-97024f4f529a@github.com>
 <j7pOVmjxxK1CVYBJzpfVGYTNTH1v0Ee3Gp-Zbu0JQak=.a8262ff2-937c-47ce-a06c-73cf46343601@github.com>
Message-ID: <AJKSyJdqQW29EKBqkj8anqTqGI5XxJyA06UtsOJRA60=.0e3b5082-2595-487e-b772-5eb7189145c1@github.com>

On Thu, 26 Sep 2024 11:51:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > jni_md.h seems like a pretty big sledgehammer for something that seems to only be in one file, for just java.desktop. Is this macro planned to be used outside of java.desktop?
> 
> Yes I have a couple (currently 2) more I would like to exclude as well . The exclusions should work (similar to HS) for the whole JDK C codebase.

Alright, if this is planned to be used across the entire JDK and not just in java.desktop then I guess this should be ok. Indeed, perhaps a ubsan.h header would be appropriate for a macro like this. I'll leave that up to further discussion

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2377128778

From bpb at openjdk.org  Thu Sep 26 15:23:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 26 Sep 2024 15:23:42 GMT
Subject: Integrated: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer
In-Reply-To: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
Message-ID: <F4FVXXFXiqOHjdN-Q2e3UTeW2Mdu29db_W3edXwOXl8=.49b39c15-e0b1-4cbd-a594-c2fb2adc19e2@github.com>

On Thu, 25 Jul 2024 00:24:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.

This pull request has now been integrated.

Changeset: aeaa4f78
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aeaa4f78ebd634c2020d0f0dd100fcb55d5130af
Stats:     46 lines in 4 files changed: 23 ins; 0 del; 23 mod

8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20320

From darcy at openjdk.org  Thu Sep 26 16:05:42 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 16:05:42 GMT
Subject: Integrated: 8340981: Update citations to "Hacker's Delight"
In-Reply-To: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
References: <NNp5Q1pALxuwE37SCd33qud1w0gbcb3oSXVn6ztPJkk=.55245b6d-f506-42ea-97dc-639b7d3d250d@github.com>
Message-ID: <xuupVrWQXznrbRqV1mjHViDc8dXfv5wueqk3ANTgOFY=.4ad723be-6b15-44aa-8b05-b0eacae5d724@github.com>

On Wed, 25 Sep 2024 22:58:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add citation of the second edition of "Hacker's Delight".

This pull request has now been integrated.

Changeset: 8225a5f5
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8225a5f58a62ddf4acbb879bfcb53cf7bfd8542f
Stats:     10 lines in 2 files changed: 2 ins; 0 del; 8 mod

8340981: Update citations to "Hacker's Delight"

Reviewed-by: bpb, iris, liach, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/21194

From darcy at openjdk.org  Thu Sep 26 16:07:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 16:07:41 GMT
Subject: Integrated: 8340983: Use index and definition tags in Object and
 Double
In-Reply-To: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>
References: <J9LqndquNN5Wl1n_t24YRBX2kVSjpsTa6gTc4z23Zww=.b4f018c0-7a03-4545-a3c1-e33f51b2a3f0@github.com>
Message-ID: <Tj_Z6H-pjGwqBnha15GFI-OWWEOwlp1YyIaJu2soEhA=.d4dbe86e-43b9-43e9-9d5e-2caa22d51680@github.com>

On Wed, 25 Sep 2024 23:17:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple change to add a few more index tags on terms related to equality and equivalence.

This pull request has now been integrated.

Changeset: bb040ef4
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb040ef4cc2b626f282cbf6af5b359d1c2505385
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8340983: Use index and definition tags in Object and Double

Reviewed-by: bpb, liach

-------------

PR: https://git.openjdk.org/jdk/pull/21195

From cjplummer at openjdk.org  Thu Sep 26 16:20:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 26 Sep 2024 16:20:38 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
Message-ID: <EIgPRPPps4JFWQNlv_Gxp4Zo94bNVp3I3YSOenYP7Dg=.7518f304-0842-4102-9aad-0f039a2b8128@github.com>

On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
>> 
>> 
>> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
>> 
>> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
>> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
>> 3. Some parts of the code are written in C others in C++.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix missing code

I don't have a suggestion for maintaining compatibility other than not making the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2377406509

From naoto at openjdk.org  Thu Sep 26 16:28:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Sep 2024 16:28:36 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v4]
In-Reply-To: <5R8L6xIMINEPo0g5YleaQTtJ3LHMvYRbMmBX6C-buBI=.8d3491c8-4457-41df-a3d2-a4034adf4b93@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <5R8L6xIMINEPo0g5YleaQTtJ3LHMvYRbMmBX6C-buBI=.8d3491c8-4457-41df-a3d2-a4034adf4b93@github.com>
Message-ID: <UwjQNuF2BjNa6vaUnN0hJ1BtCTHdczkzEwB1fct-teo=.3f3c8f90-c5d2-4228-88fc-606304e549ba@github.com>

On Wed, 25 Sep 2024 23:32:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/sun/net/www/ParseUtil_6380332.java
>>   - Outdated test that checks a SunTea applet
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: update wording of instructions

LGTM

test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 80:

> 78:               6. Turn on "Adjust for daylight saving time automatically"
> 79: 
> 80:             If the local time in the control panel and test window are always the same,

nit: "control panel" -> "Settings app"

-------------

PR Review: https://git.openjdk.org/jdk/pull/21096#pullrequestreview-2331813551
PR Review Comment: https://git.openjdk.org/jdk/pull/21096#discussion_r1777409415

From dfuchs at openjdk.org  Thu Sep 26 17:09:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Sep 2024 17:09:57 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v5]
In-Reply-To: <OARpADdNS2uooJ2iirCGbBQQPndQwiYAVfDDPgK_Ods=.d59f8514-75f9-48af-8bbe-8ccde316474c@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <OARpADdNS2uooJ2iirCGbBQQPndQwiYAVfDDPgK_Ods=.d59f8514-75f9-48af-8bbe-8ccde316474c@github.com>
Message-ID: <gA_IP15oDJqMXked7odlmzEXfNvT92G6w1AosFD96vY=.2cdf7c48-b942-40dd-a663-aca220ca1a59@github.com>

On Thu, 26 Sep 2024 17:00:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/sun/net/www/ParseUtil_6380332.java
>>   - Outdated test that checks a SunTea applet
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace last control panel instance with Settings app

`test/jdk/sun/net/www/ParseUtil_6380332.java`: shouldn't we actually keep this test? I see that the code in ParseUtil which is tested here is still there, and I don't think we'd want to touch ParseUtil given potential compatibility issues that might arise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21096#issuecomment-2377495252

From nbenalla at openjdk.org  Thu Sep 26 17:13:39 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Sep 2024 17:13:39 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
Message-ID: <TcIHfGvsc0FuTGUrNIo9NmrHyhQCKDfVFYQUdBFlM8Q=.7d1d7f5d-f6e1-4d07-8f1c-7ce888f5e658@github.com>

On Thu, 26 Sep 2024 08:16:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Updated copyright years
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
>  - Merge branch 'master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
>    #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I ran it and all the tags seem to be correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2377503375

From jlu at openjdk.org  Thu Sep 26 17:24:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 26 Sep 2024 17:24:18 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v6]
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <kI0j0PN7ZTKY71ZbhRMOPigZtfdSRM_c_Pf3OIe12dI=.bfb690e1-1fb0-4023-b7de-d43874c5af8f@github.com>

> Please review this PR which removes usages of Applet within the corelibs tests.
> 
> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
> 
> The following files were removed,
> 
> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>   - Test runner is no longer an Applet, so not needed
> - test/jdk/java/net/Socket/SocketImplTest.java
>   - An old Applet test missing Jtreg tags.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  restore ParseUtil_6380332.java test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21096/files
  - new: https://git.openjdk.org/jdk/pull/21096/files/d1822f48..c90218e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=04-05

  Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21096/head:pull/21096

PR: https://git.openjdk.org/jdk/pull/21096

From jlu at openjdk.org  Thu Sep 26 17:24:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 26 Sep 2024 17:24:18 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v5]
In-Reply-To: <gA_IP15oDJqMXked7odlmzEXfNvT92G6w1AosFD96vY=.2cdf7c48-b942-40dd-a663-aca220ca1a59@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <OARpADdNS2uooJ2iirCGbBQQPndQwiYAVfDDPgK_Ods=.d59f8514-75f9-48af-8bbe-8ccde316474c@github.com>
 <gA_IP15oDJqMXked7odlmzEXfNvT92G6w1AosFD96vY=.2cdf7c48-b942-40dd-a663-aca220ca1a59@github.com>
Message-ID: <IR9bsNXrcqq9T7KSiWVHWCXqQeKeQgrPYSk055IRwks=.a3eb9b01-1375-4350-b324-56601d974fdf@github.com>

On Thu, 26 Sep 2024 17:06:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `test/jdk/sun/net/www/ParseUtil_6380332.java`: shouldn't we actually keep this test? I see that the code in ParseUtil which is tested here is still there, and I don't think we'd want to touch ParseUtil given potential compatibility issues that might arise.

Hi Daniel,

You're right, I looked at that test too fast. While there are similar tests testing `ParseUtil.toURI`, _ParseUtil_6380332.java_ tests the specific -1 port number case.

Restored the test, and instead updated the summary in https://github.com/openjdk/jdk/pull/21096/commits/c90218e907b017b547f76a7010b9b87ca43f705a. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21096#issuecomment-2377519268

From asotona at openjdk.org  Thu Sep 26 17:35:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Sep 2024 17:35:36 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <TcIHfGvsc0FuTGUrNIo9NmrHyhQCKDfVFYQUdBFlM8Q=.7d1d7f5d-f6e1-4d07-8f1c-7ce888f5e658@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
 <TcIHfGvsc0FuTGUrNIo9NmrHyhQCKDfVFYQUdBFlM8Q=.7d1d7f5d-f6e1-4d07-8f1c-7ce888f5e658@github.com>
Message-ID: <KvmN5DbwlGlNNAMMKfh3anymX7_J6-Q1R-TL53Riwok=.a0767f21-84fb-402e-b219-e455edee2cf1@github.com>

On Thu, 26 Sep 2024 17:11:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I ran it and all the tags seem to be correct.

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2377551118

From dfuchs at openjdk.org  Thu Sep 26 17:40:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Sep 2024 17:40:37 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v6]
In-Reply-To: <kI0j0PN7ZTKY71ZbhRMOPigZtfdSRM_c_Pf3OIe12dI=.bfb690e1-1fb0-4023-b7de-d43874c5af8f@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <kI0j0PN7ZTKY71ZbhRMOPigZtfdSRM_c_Pf3OIe12dI=.bfb690e1-1fb0-4023-b7de-d43874c5af8f@github.com>
Message-ID: <ZCVanr0vN9_60tQsWsgjFDT51dSjUOTjY1OaRD1ftjg=.1bb1f4be-381d-4b28-9557-b626d950d24f@github.com>

On Thu, 26 Sep 2024 17:24:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore ParseUtil_6380332.java test

Logging and sun/net changes look reasonable to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21096#pullrequestreview-2331962137

From rotanolexandr842 at gmail.com  Thu Sep 26 20:00:10 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 26 Sep 2024 23:00:10 +0300
Subject: Range API
In-Reply-To: <f8fda70c-9eb5-4cdc-beb7-04a4c83616b8@oracle.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
 <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
 <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>
 <5320CD47-A9EB-44BE-994B-F296FC281D3A@cbfiddle.com>
 <CAL5bRt9zu_WtHUi-0J2L5LThpWfCaGWCrd5cxLHNkJJ52uHHxA@mail.gmail.com>
 <f8fda70c-9eb5-4cdc-beb7-04a4c83616b8@oracle.com>
Message-ID: <CAL5bRt_COc7apvQbWucbwzNWdQa+vYggrRhB_fnLNtZKUNvP=Q@mail.gmail.com>

>
> but I also don't sense people beating down the doors for that (even if the
> language had range literals, like `0..<100`).


True, that what I was thinking also: "is iteration over numeric range is so
important to challenge general versatility of API?", but

for (int j=index; j<index+target.length(); j++)


is the use case that I haven't even thought of. After some research, I
found a family of methods across jdk that could benefit from ranges. Their
names match X::indexOf(X) or X::indexOfSubX(X) or similar patterns. I did
some research and found it surprising that the only young language, which
all now have first-class support for ranges, that takes advantage of range
return types is Swift and its string::range(of: substring) (maybe there is
similar methods for sublists in Swift, I think it is not that significant).
Others either return an optional int or int itself.

Much more languages, though, have adapted ranges as input parameters for
slicing and other range-specifying operations, not lastly due to issues like

Similarly, I see errors in API usage because sometimes we specify range by
> (start, end) and sometimes by (start, length)


Though, there are some differences with the vast majority of languages and
this API currently, mostly with the fact that almost all languages do not
support any range algebra out-of-the-box (closest I have seen were
itertools in Rust), and, subsequently, there is nowhere to emerge for unios
from, unlike current implementation. Adapting return types for being
three-state algebraic data types (i.e. result of passing empty range,
result of passing uninterrupted and result of passing union) is not that
hard, but just another work to do in case similar APIs would be adopted in
jdk.

My research about iterability of ranges in other languages showed that
there is, unfortunately, no magic pill invented. Basically, there are two
approaches to making range iterable:

1) Implement iterator
2) Implement increment/decrement

The concrete way might vary from traits in Rust (and something like this in
Haskell I suppose) to operator overloading in c++, but concepts are the
same. Most languages also provide out-of-the-box support for integer
ranges.

And that is what I concluded on, at least for now. I think that API should
provide support for any custom iteration strategy using something like
Collector/Gatherer wrappers over a functional interface that will transform
increment/decrement function into iterator. Besides that, I think that it
makes sense to create separate Range.OfInts(int, int) or just
Range.of(int,int) overload, that will return thin extension of
Range<Integer> (noone convinces me to create new specialized class), that
implements iterable using simple int increments, which would both benefit
the performance and address most of the use cases for "obviously iterable"
ranges. I also think there is no need for open iterable ranges, even if
start-closed. I think it is better to have some method to return Stream
than implement Iterable, since this might lead to unexpected problems.

Best regards

On Thu, Sep 26, 2024 at 4:30?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Sorry for the not-good news, but I'm not too surprised.  Computational
> domains like "32 bit integers" seem like they should have a lot in common
> with algebraic structures like groups and rings, but when you start poking
> at them, the compromises we make to fit them into hardware registers start
> to bite.  (And let's not get started on floating point...)  Lots of
> research into numeric towers in various languages, or capturing fundamental
> properties in type classes like Haskell's `Eq` and `Ord`, offers plenty of
> compromise to go with its promise.
>
> I think a big part of what you are running into is that you've started
> with a _concept_ (a deceptively simple one, at that), rather than
> _requirements_.  And it is the open-endedness of this concept (discrete vs
> continuous, bounded vs half-open, including endpoints or not, etc) that
> resists abstraction.  Plus, without clear requirements, you will be subject
> to an endless barrage of "what about my pet use case" (e.g., "what about
> the numbers zero to ten, advancing by two").  Meanwhile, domain-specific
> libraries such as java.time will invent their own domain-specific answers,
> like Interval.
>
> Rather than starting from the algebraic properties, perhaps start from the
> other end: what are the use cases where the lack of a range abstraction is
> problematic.  I get that
>
>     for (int i=0; i<100; i++) { ... }
>
> is uglier and less abstract than
>
>     for (int i : Range.of(0, 100)) { ... }
>
> but I also don't sense people beating down the doors for that (even if the
> language had range literals, like `0..<100`).
>
> Where I do see people having trouble is that many range computations are
> error prone.  For example, `String::indexOf` returns the starting index of
> a match; if you want to actually iterate over the characters of such a
> match, you have to do something like
>
>     for (int j=index; j<index+target.length(); j++)
>
> and you are at risk for fencepost errors when recreating the range.
> Whereas an indexOf method (under a more suitable name) that returned a
> range, would be more amenable to downstream processing.  Similarly, I see
> errors in API usage because sometimes we specify range by (start, end) and
> sometimes by (start, length), and since both are ints, we get no type
> checking when you pass the wrong kinds of ints to such a method.
>
> But, the mere existence of a Range type would do little to help String,
> Arrays, and other range-happy APIs, because we would have to update them to
> include new overloads that dispense and consume ranges.  So that's a big
> project.
>
> Still, I think investigating use cases involving libraries that work
> intensively with ranges like this would likely yield useful information for
> what a Range type would want to provide.
>
> HTH,
> -Brian
>
>
>
>
>
>
> On 9/26/2024 9:07 AM, Olexandr Rotan wrote:
>
> Researching the of deriving some iterable representations from ranges, and
> I am not here with the good news.
>
> Unlike range algebra and boolean operations, which generalize
> extremely well, iterability of ranges... Well, it's safe to say it
> doesn't generalize at all. Analyzing key features people expect iterable
> ranges to have, I ended up concluding there are basically two groups / two
> use cases for them. First is plain and simple, arguably the most popular
> one: iterating over a range of integer numbers, i.e. `for (i : Range.of(1,
> 10))`. Another use case is for more complex iterations over ranges of
> reference types, most commonly dates/time.
>
> There are two groups of values by their nature: discrete and continuous.
> Most of the types belong to the second group, as there is no direct
> increment AND decrement for them (we will omit hardware limitations for
> simplicity), such as floating point values. What is the increment of 1,3?
> 1.31 or 1.30000000001, or maybe something even more unreadable? On the
> other hand, the increment of LocalDate in context of range iteration that
> represents today is rather obvious - it is tomorrow.
>
> There is a pretty limited number of discrete types in jdk. Dates, whole
> numbers and basically that's it. The discrete types that are not present in
> jdk can be really various. For example, users can define a comparable
> type "F1Team" and compare them based on their position in the last race.
> There, increment would most likely be the next team in rating. There are
> many domain-specific cases like this.
>
> This is where the problem comes from. If the user would always have to
> pass a comparator to create a range, it would be consistent to make the
> user define increment/decrement as well. But we don't want users to pass a
> comparator if the type is already comparable. Similarly, we don't want
> users to define increment/decrement if there is already one in the
> language! I think defining increments for dates (say LocalDate.plusDays(1))
> would be acceptable, even defining increments for floats in context of
> ranges might be acceptable, but making people define increments for
> integers is, in my opinion, completely not. Besides performance impact,
> this is a terrible user experience.
>
> There are a few solutions to this:
> 1) Define ton of overrides for factory methods and specialized types for
> this (uhh, sounds awful)
> 2) Introduce new interface, say Discrete<T>, that defines T increment()
> (and possible T decrement()) methods. From now on, there are 2 branches:
> 2.1) Leave things as is, allow users to define incrementation logic for
> their types, but don't touch integers and other built-ins.I see this option
> as extremely inconsistent and not solving the main issue, which is
> iterability of integers.
> 2.2) Retrofit (scary) existing types to implement this interface. This
> should not have any compatibility nor security implications, but still
> sneaking into java.lang every time we need some new API to be more
> user-friendly is obviously not a way to go. This basically comes down to a
> question about how deep we want to integrate ranges into language, and is
> range  generalization even worth the invasion into the core of
> language (imo yes).
> 3) Leave things as they are, just let users derive iterables using
> something like range.asIterableWithStep(IncremetStartegy increment). I
> think this would make an API too narrow as no one will use it for routine
> tasks the same way people do in Rust, Kotlin and other languages.
>
> I would love to hear community opinion on this matter. Which option is the
> most preferable, maybe some compromise between a few of them, or maybe
> there is a better way to go that I didn't mention here?
>
> Best regards
>
> On Tue, Sep 24, 2024 at 5:11?PM Alan Snyder <javalists at cbfiddle.com>
> wrote:
>
>> I have another example: I have a datatype that represents a region of an
>> audio track, for example, one tune in a medley of tunes. I allow the region
>> to
>> specify both a start and end time, but the end time is optional (and
>> mostly not used). When the end time is not specified, the region ends at
>> the start of the next region, or at
>> the end of the track if there is no next region. The latter case is
>> useful because the exact track length may not be known. The optionality of
>> the end time
>> is not represented in the type system.
>>
>> Having said that, I?m not sure that a general abstract interface would be
>> useful for this example.
>>
>> On Sep 24, 2024, at 2:13?AM, Olexandr Rotan <rotanolexandr842 at gmail.com>
>> wrote:
>>
>> As part of the redesigning  process , I am researching whether or not
>> there are use cases that require asserting that the range is exactly
>> half-bounded. This is important because I plan to switch to
>> BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime
>> checks: Here is what I gathered for now.
>>
>>
>>    - *Date/Time Handling (Historical or Forecast Data)*: When dealing
>>    with events that started at a specific time but have no known end (e.g.,
>>    open-ended employment contracts or ongoing subscriptions)
>>    - *Stream Processing (Real-time Event Streams)*: In real-time
>>    systems, you might process data that has a start time but no defined end,
>>    such as monitoring a live video feed or logging system. The range is
>>    bounded at the start and unbounded at the end as more data will
>>    continuously arrive.
>>    - *Data Pagination (Fetch Until Condition)*: When implementing
>>    pagination, sometimes you might want to fetch items starting from a
>>    specific index up to an unbounded limit (e.g., fetching all items after a
>>    certain point until memory runs out or a condition is met).
>>    - *Auditing and Monitoring*: In systems where audit trails or logging
>>    data should capture all events after a certain point (bounded start) with
>>    no foreseeable end (unbounded end), such as monitoring changes to records
>>    in a database starting from a fixed timestamp.
>>    - *Scientific or Statistical Ranges*: When modeling physical systems
>>    or statistical ranges, you might want to capture measurements that begin at
>>    a known threshold but theoretically have no upper or lower bound. For
>>    example, recording temperature data starting at absolute zero and
>>    increasing without any known upper limit.
>>    - *Inventory or Resource Allocation*: Resource allocation policies,
>>    such as those for virtual machines, may be based on known minimum
>>    allocation thresholds but have flexible or unbounded resource caps,
>>    depending on availability.
>>
>>    I am writing to ask whether anyone who worked with such systems could
>>    confirm/deny that those are real use cases. If so, would it be satisfying
>>    enough to assert one-way unboundness with instanceof checks, i.e. range
>>    instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange).
>>    Would appreciate any feedback.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240926/6c6e334f/attachment-0001.htm>

From prr at openjdk.org  Thu Sep 26 21:05:36 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Sep 2024 21:05:36 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v4]
In-Reply-To: <UwjQNuF2BjNa6vaUnN0hJ1BtCTHdczkzEwB1fct-teo=.3f3c8f90-c5d2-4228-88fc-606304e549ba@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <5R8L6xIMINEPo0g5YleaQTtJ3LHMvYRbMmBX6C-buBI=.8d3491c8-4457-41df-a3d2-a4034adf4b93@github.com>
 <UwjQNuF2BjNa6vaUnN0hJ1BtCTHdczkzEwB1fct-teo=.3f3c8f90-c5d2-4228-88fc-606304e549ba@github.com>
Message-ID: <chqPKDzEo3ljIm13E02-IWZNDYTS-25Ts1Ujhs3X75c=.35bdaf7f-1578-4b06-97cb-68073405824c@github.com>

On Thu, 26 Sep 2024 16:25:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: update wording of instructions
>
> test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 80:
> 
>> 78:               6. Turn on "Adjust for daylight saving time automatically"
>> 79: 
>> 80:             If the local time in the control panel and test window are always the same,
> 
> nit: "control panel" -> "Settings app"

FWIW on my WIndows 11 system both Settings and Control Panel provide this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21096#discussion_r1777731071

From prr at openjdk.org  Thu Sep 26 21:27:35 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Sep 2024 21:27:35 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>

On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

This needs careful thinking about by various parties.
I am not sold on it, and the build team have indicated they do not support --enable-ubsan and my experience with that and similar options is that they are a nightmare to find a system on which they build and produce a working binary.

Until there's solid committed support by the leads of the build team I don't think we should be considering these kinds of PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2377966195

From naoto at openjdk.org  Thu Sep 26 21:41:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Sep 2024 21:41:36 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v4]
In-Reply-To: <chqPKDzEo3ljIm13E02-IWZNDYTS-25Ts1Ujhs3X75c=.35bdaf7f-1578-4b06-97cb-68073405824c@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <5R8L6xIMINEPo0g5YleaQTtJ3LHMvYRbMmBX6C-buBI=.8d3491c8-4457-41df-a3d2-a4034adf4b93@github.com>
 <UwjQNuF2BjNa6vaUnN0hJ1BtCTHdczkzEwB1fct-teo=.3f3c8f90-c5d2-4228-88fc-606304e549ba@github.com>
 <chqPKDzEo3ljIm13E02-IWZNDYTS-25Ts1Ujhs3X75c=.35bdaf7f-1578-4b06-97cb-68073405824c@github.com>
Message-ID: <1eQl_bGhy7sB6VECuDauK5ZfJMyInS0lsjBPPv2CDEM=.a9ca6f81-a79a-4f8b-946f-cdc074b8d54b@github.com>

On Thu, 26 Sep 2024 21:03:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 80:
>> 
>>> 78:               6. Turn on "Adjust for daylight saving time automatically"
>>> 79: 
>>> 80:             If the local time in the control panel and test window are always the same,
>> 
>> nit: "control panel" -> "Settings app"
>
> FWIW on my WIndows 11 system both Settings and Control Panel provide this.

Yes, but they are sunsetting Control Panel.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21096#discussion_r1777760400

From darcy at openjdk.org  Thu Sep 26 23:51:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 23:51:43 GMT
Subject: RFR: 8341064: Define anchor point and index term for "wrapper classes"
Message-ID: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>

The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

-------------

Commit messages:
 - JDK-8341064: Define archor point and index term for "wrapper classes"

Changes: https://git.openjdk.org/jdk/pull/21215/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341064
  Stats: 28 lines in 2 files changed: 8 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21215/head:pull/21215

PR: https://git.openjdk.org/jdk/pull/21215

From darcy at openjdk.org  Thu Sep 26 23:51:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Sep 2024 23:51:43 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes"
In-Reply-To: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
Message-ID: <3-CV23-igzwSLD65CVItxSH46bnszl9HR-An112HnzM=.0cfde444-800a-4d13-bd57-cbb828874e46@github.com>

On Thu, 26 Sep 2024 23:46:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

For now, of the wrapper classes, I only updated the Integer with the proposed new wording. Once a final wording is determined, I'll make the analagous changes in the other classes.

The current listing of the wrapper classes in the java.lang package-info file omits Short. I'll re-flow those paragraphs once the wording update is settled on.

For another in-progress PR, https://git.openjdk.org/jdk/pull/21193, it would be helpful for "wrapper classes" to be a term that could be linked to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21215#issuecomment-2378131887

From swen at openjdk.org  Fri Sep 27 01:34:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 27 Sep 2024 01:34:18 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames [v2]
In-Reply-To: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
Message-ID: <6Ti1R4kgPQBmivebRnrIEN3o74woLqUuCqGLMF7ylsk=.ae6813f5-aabf-4748-a608-965cfe6da475@github.com>

> 1. Construct Frames directly without BitSet
> 2. Use Frame[] instead of ArrayList
> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.

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/21183/files
  - new: https://git.openjdk.org/jdk/pull/21183/files/0ea67959..905acdda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21183&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21183&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21183/head:pull/21183

PR: https://git.openjdk.org/jdk/pull/21183

From henryjen at openjdk.org  Fri Sep 27 01:41:18 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 27 Sep 2024 01:41:18 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v2]
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <ZM804HuiistgEnzRJbHrIM4N0HmpzMSA4cgtGLroWdA=.810d42ba-7382-477d-b6a5-6323dd3b6f88@github.com>

> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
> 
> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
> 
> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
> 
> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
> 
> So we make this build in advance, and use a static array for values referred more than once.
> 
> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21022/files
  - new: https://git.openjdk.org/jdk/pull/21022/files/db79e46f..ffce5eba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=00-01

  Stats: 22 lines in 1 file changed: 1 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21022/head:pull/21022

PR: https://git.openjdk.org/jdk/pull/21022

From henryjen at openjdk.org  Fri Sep 27 01:41:33 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 27 Sep 2024 01:41:33 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedbacks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21141/files
  - new: https://git.openjdk.org/jdk/pull/21141/files/de53309d..6192de61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=02-03

  Stats: 284 lines in 4 files changed: 246 ins; 10 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

PR: https://git.openjdk.org/jdk/pull/21141

From swen at openjdk.org  Fri Sep 27 01:42:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 27 Sep 2024 01:42:37 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v3]
In-Reply-To: <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
Message-ID: <9GRE2OSpfvNRHksWQe6LN9yTJswSjasq6hT9VCRWXL0=.4802a96d-9388-4aa8-acd5-767019b6c0d3@github.com>

On Wed, 25 Sep 2024 01:10:04 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - inflateNonAscii
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - optimize Utf8EntryImpl inflate
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Suggestions from @liach
>  - fix build error
>  - optimize Utf8EntryImpl inflate

I don't have a test scenario for inflateNonAscii, and I can't see the codeSize of inflateNonAscii printed in the compiler log.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20767#issuecomment-2378238661

From henryjen at openjdk.org  Fri Sep 27 01:46:36 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 27 Sep 2024 01:46:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
Message-ID: <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>

On Tue, 24 Sep 2024 19:16:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8335912: Add an operation mode to the jar command when extracting to not overwriting existing files
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 169:
> 
>> 167:         extracted: {0}
>> 168: out.kept=\
>> 169:         \ \ skipped: {0}
> 
> We might want to add a bit more wording to indicate it is being skipped due to the file already existing on disk

I follow existing pattern with short status update. Open to suggestions.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 316:
> 
>> 314: main.help.opt.extract.keep-old-files=\
>> 315: \  -k, --keep-old-files       Do not overwrite existing files.\n\
>> 316: \                             In particular, if a file appears more than once in an\n\
> 
> In addition, we need to update the help to clarify -x. --extract behavior that it will overwrite by default.
> 
> Here is the verbiage from tar to give you a start
> 
> ` -x      Extract to disk from the archive.  If a file with the same name appears more than
>              once in the archive, each copy will be extracted, with later copies overwriting
>              (replacing) earlier copies.  The long option form is --extract.`

Updated.

> test/jdk/tools/jar/ExtractFilesTest.java line 32:
> 
>> 30:  * @build jdk.test.lib.Platform
>> 31:  *        jdk.test.lib.util.FileUtils
>> 32:  * @run testng ExtractFilesTest
> 
> Please convert the test to use junit as we are moving away from testng

Done. Also add a test case for multiple manifest files in the same archive as we mentioned such use case in the help text.

> test/jdk/tools/jar/ExtractFilesTest.java line 94:
> 
>> 92: 
>> 93:     @Test
>> 94:     public void testExtract() throws IOException {
> 
> Please consider adding comments introducing the methods used by the test

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777910329
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777909703
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777911075
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1777910602

From mbaesken at openjdk.org  Fri Sep 27 06:48:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Sep 2024 06:48:34 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
Message-ID: <kzaKJvULt9BpWyh-xiePRrDa4zfR_3xbRsVnn_LELoE=.d4ddfaa6-c4ee-4a17-b845-df4111ecd713@github.com>

On Thu, 26 Sep 2024 21:25:07 GMT, Phil Race <prr at openjdk.org> wrote:

> build team have indicated they do not support --enable-ubsan 

What 'build team' are you talking about ? Some Oracle internal build team?
The ubsan support came in 2023, so nothing new (change was from Justin King)
https://github.com/openjdk/jdk/commit/7a85d95e828283d57e1df0344be454626470675d
And it was reviewed by erikj and ihse, I think those are members of the OpenJDK build group and very competent OpenJDK reviewers.
So the flag is as good or bad as any other configure flag of OpenJDK .

>and my experience with that and similar options is that they are a nightmare to find a system on which they build

We use and run this regularly on SUSE and Ubuntu Linux and have VERY good experience with it. It works (at least on recent Linux distros) very well. (on macOS our experience is a bit different there I had a couple of issues with ubsan)
A lot of large C/C++ based OSS projects support it like Linux kernel, Android, Chromium etc.
https://docs.kernel.org/dev-tools/ubsan.html
https://source.android.com/docs/security/test/ubsan
https://www.chromium.org/developers/testing/undefinedbehaviorsanitizer/

and btw.  Oracle blogs happily about it too and recommends it 
https://blogs.oracle.com/linux/post/improving-application-security-with-undefinedbehaviorsanitizer-ubsan-and-gcc
So it is a well established tool in the OSS world.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2378520093

From jwaters at openjdk.org  Fri Sep 27 07:09:37 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 27 Sep 2024 07:09:37 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <kzaKJvULt9BpWyh-xiePRrDa4zfR_3xbRsVnn_LELoE=.d4ddfaa6-c4ee-4a17-b845-df4111ecd713@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
 <kzaKJvULt9BpWyh-xiePRrDa4zfR_3xbRsVnn_LELoE=.d4ddfaa6-c4ee-4a17-b845-df4111ecd713@github.com>
Message-ID: <Jrzwm6hTlBFhVxBYBGyzCr9xEKVzCAUOtz8KPQYtOvU=.5ec11b1e-5364-40db-bea5-1b6727448210@github.com>

On Fri, 27 Sep 2024 06:46:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> And it was reviewed by erikj and ihse, I think those are members of the OpenJDK build group

Erik and Magnus are indeed part of the build team. Erik is the Skara tool lead but does build work as well, while Magnus is pretty much the face of the build team at this point



> very competent OpenJDK reviewers

If only I could be a competent reviewer one of these days :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2378552970

From mbaesken at openjdk.org  Fri Sep 27 07:46:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Sep 2024 07:46:34 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <5F8WL1Qh0Lq_JHGMORBPlnpcNwJ8TDR4hZei-R2tcpA=.83d0a9fe-4682-44f8-a57f-3a6cccfd3fc8@github.com>

On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

Btw regarding the function/method exclusion, this was introduced in HS some time ago 
https://bugs.openjdk.org/browse/JDK-8334239
We just needed in HS codebase a couple of places where we use/keep undefined behavior  (e.g. im vmError.cpp where it is intentionally used).  Obviously, the mentioned HS change does not work for the other C libs so this is some kind of follow up.
In HS we use the ATTRIBUTE_NO_UBSAN macro currently at 4 code locations.  So it is not intended or likely that this macro would go to a lot of places of the JDK libs, just a small number comparable to usage in HS.
Regarding putting  it into jni_md.h, probably it would moving it from there to a separate header like it is done in HS would be better, I can do that if this is preferred.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2378625842

From prappo at openjdk.org  Fri Sep 27 09:36:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 27 Sep 2024 09:36:37 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes"
In-Reply-To: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
Message-ID: <3hO_xQd_OMxjCSOVPsfXyLjHLaImY8WPz0TTHP1csGs=.639490ec-b4eb-4c38-99b4-c7e8811a5b56@github.com>

On Thu, 26 Sep 2024 23:46:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

src/java.base/share/classes/java/lang/package-info.java line 36:

> 34:  * The <dfn>{@index "wrapper classes"}</dfn> {@link Boolean},
> 35:  * {@link Character}, {@link Short}, {@link Integer}, {@link Long}, {@link Float},
> 36:  * and {@link Double} serve this purpose.  An object of type {@code

Somehow, `Byte` is missing from that list. To be fair, it had been missing before this PR.

src/java.base/share/classes/java/lang/package-info.java line 45:

> 43:  * These classes also provide
> 44:  * a number of methods for converting among primitive values, as well
> 45:  * as supporting such standard methods as {@code equals} and {@code hashCode}.  The

While the bulk of this sentence has unchanged, it read weirdly because of it's non-parallel structure:

"These classes ... provide ... methods for converting ..., as well as supporting ... methods ... equals and hashCode."

Consider these alternatives:

1. "These classes ... provide ... methods for converting ..., as well as support ... methods ... equals and hashCode."

2. "These classes ... provide ... methods for converting ..., as well as for supporting ... functionality of equals and hashCode."

src/java.base/share/classes/java/lang/package-info.java line 63:

> 61:  * security policies.
> 62:  *
> 63:  * <p>Class {@link Throwable} encompasses objects that may be thrown

We already have a link to `Class` in this doc comment. This one can stay `{@code Class}`, which might be easier to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1778306710
PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1778326694
PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1778311130

From alanb at openjdk.org  Fri Sep 27 11:15:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Sep 2024 11:15:35 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v5]
In-Reply-To: <nLhPjQbCLgZW2eNpwkeTwp0StAxDBhb_u8Y3HRaukmE=.86c9ae91-ddce-4493-a888-665f8f7f6589@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <nLhPjQbCLgZW2eNpwkeTwp0StAxDBhb_u8Y3HRaukmE=.86c9ae91-ddce-4493-a888-665f8f7f6589@github.com>
Message-ID: <BgVpitlVG7D3NB8EN9zFseK3sI3tRd4gaJN8zCDHCNE=.45974ca7-e145-402a-a777-faac0a92f959@github.com>

On Thu, 26 Sep 2024 00:49:20 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comments

src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 1095:

> 1093:             moduleToReader.clear();
> 1094:         }
> 1095:     }

Do you remember why resetArchivedStates resets the resource cache? I would expected it to be cleared for all class loaders.

Rather than putting something specific to the app class loader here then maybe it should be renamed and have resetArchivedStates call it, e.g.


    void resetArchivedStates(boolean all) {
        ucp = null;
        resourceCache = null;
        if (all) {
            moduleToReader.clear();
        }
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1778453669

From alanb at openjdk.org  Fri Sep 27 11:15:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Sep 2024 11:15:37 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <B9_yEeuGFbptYX51_EhJKjMMPylpB4_qUdZjCFrQQhA=.67cb1008-7c64-4704-bab0-1f10c3ab558e@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
 <p_rRUuAYIri6ve8E-FKQzeqVQG2LRa5LL368xHYvcBc=.905f0ce3-a95b-43b8-bbae-2f812004c38b@github.com>
 <B9_yEeuGFbptYX51_EhJKjMMPylpB4_qUdZjCFrQQhA=.67cb1008-7c64-4704-bab0-1f10c3ab558e@github.com>
Message-ID: <rxlS_gLbxMiXd_td1kQ_ZKZ7ClWg_461CG22RBc4-mY=.28aa6563-fb1d-4f23-bc90-13e3fd219a2c@github.com>

On Tue, 24 Sep 2024 21:17:35 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 481:
>> 
>>> 479:                     cf,
>>> 480:                     clf,
>>> 481:                     mainModule);
>> 
>> This was correctly aligned before, now it isn't.
>
> Fixed.

That may have been my fault, I gave Calvin changes to check the configuration and the IDE re-formatted it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1778455739

From alanb at openjdk.org  Fri Sep 27 11:15:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Sep 2024 11:15:37 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v3]
In-Reply-To: <ubDPqGHy-8mHVHBksyOMaZkRtdpJAlddvpYX8ykDSVY=.1b0b6255-eff6-4f00-9efa-e1734d46e618@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <TZ6tiQUlNf2inEJUS2i6BGaDbzjKbOWDkygYsI7QHq4=.d9a2db54-ee29-44d6-b60b-670642fc54e6@github.com>
 <7x-dr_M70dbSsP6Jr-QIY1g40vSdKMnXmkwfuUElzDg=.ca786a00-1613-4db3-a53b-0ce01942e5bd@github.com>
 <ubDPqGHy-8mHVHBksyOMaZkRtdpJAlddvpYX8ykDSVY=.1b0b6255-eff6-4f00-9efa-e1734d46e618@github.com>
Message-ID: <S_ANw3mRk6l9A9pmAQDtuDuzKS1cOmt9e13mKqFv9qs=.9bff7524-6422-4e29-a065-46d7e1d69559@github.com>

On Mon, 23 Sep 2024 05:57:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleReferences.java line 105:
>> 
>>> 103:             public byte[] generate(String algorithm) {
>>> 104:               return ModuleHashes.computeHash(supplier, algorithm);
>>> 105:             }
>> 
>> Why is JarModuleReader changed to use a file string, is this because of an environment dependency when using a Path?
>
> It is to avoid the following warnings during dump time:
> 
> [1.607s][warning][cds,heap  ] Archive heap points to a static field that may be reinitialized at runtime:
> [1.607s][warning][cds,heap  ] Field: java/util/zip/ZipFile$Source::builtInFS
> [1.607s][warning][cds,heap  ] Value: sun.nio.fs.LinuxFileSystem
> ...
> [1.607s][warning][cds,heap  ] Archive heap points to a static field that may be reinitialized at runtime:
> [1.607s][warning][cds,heap  ] Field: sun/nio/fs/DefaultFileSystemProvider::INSTANCE
> [1.607s][warning][cds,heap  ] Value: sun.nio.fs.LinuxFileSystemProvider

Thanks. At one point we will likely have to re-visit this we have prototype changes that re-implement ZipFile and java.io to use the newer APIs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1778454364

From shade at openjdk.org  Fri Sep 27 13:58:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 13:58:40 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
Message-ID: <jhjANqZZF-0VfNI04WkKxV1UC3CSCzsIwwW8oVy222M=.934ed6f5-9a5e-47c4-a2a6-5597a443ebe7@github.com>

On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [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:
> 
>   Amend the test case for guaranteing it works under different compilation regimes

We keep seeing `Reference.clear` native call on hot paths in services in JDK 17+. I would like to get this PR moving again. Please take a look :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2379346593

From rgiulietti at openjdk.org  Fri Sep 27 14:17:51 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Sep 2024 14:17:51 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <9idRX4b22kj-n7LiVJnOsl64iEYsLLK4KIKBj6cMhSg=.c4924ce5-a054-42dc-a54e-9b9953f75690@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
 <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
 <Wo0s8NU66pV_TyPvz3lEQ0JOGf1CnYkOG4Vm9OhK-y0=.d6156ac5-0e85-43bb-a270-e45af3c8c154@github.com>
 <9idRX4b22kj-n7LiVJnOsl64iEYsLLK4KIKBj6cMhSg=.c4924ce5-a054-42dc-a54e-9b9953f75690@github.com>
Message-ID: <B1GZkGDVraPerF1vZr2nD-31561zlOvCXHksUV1x2e8=.301707ab-1384-4546-a388-a2622532145f@github.com>

On Tue, 3 Sep 2024 16:50:26 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> > It would be nice to see some benchmarks where it gives performance benefits.
>>> 
>>> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visible...
>> 
>> "maybe"????
>> So, you don't have proof that this PR gives any performance benefits.
>> I don't think we have to make an optimization for the sake of optimizations.
>
> @kuksenko It's not only for the sake of optimization, but to make the code more clear and consistent with the implementation of `BigInteger.shiftLeft()`.

@fabioromano1 Do you plan to work for more systematic tests, as discussed [above](https://github.com/openjdk/jdk/pull/20008#discussion_r1756784216)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2379386989

From galder at openjdk.org  Fri Sep 27 14:18:41 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 27 Sep 2024 14:18:41 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v2]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <-IW4I9MWB3up_N8BClv2TvHy2lUuvDk7bGohxIPv5IU=.b2f0e1b6-3ef8-4f97-9331-a7c5ba1046d1@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 incrementally with 17 additional commits since the last revision:

 - Remove previous benchmark effort
 - Multiply array value in reduction for vectorization to kick in
 - Renamed benchmark methods
 - Add min/max benchmark that includes loops and reductions
 - Skip single array benchmarks
 - Add an intermediate % that is more representative of real life
 - Fix compilation error
 - Fix min case to distribute numbers as per probability
 - Distribute values targetting a branch percentage
   
   * Use a random increment algorithm,
   to create an array of values such that min/max
   branch percentage matches.
 - Fix format of assembly for the movl to movq switch
 - ... and 7 more: https://git.openjdk.org/jdk/compare/3dd72b89...28778c84

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/3dd72b89..28778c84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=00-01

  Stats: 562 lines in 5 files changed: 418 ins; 132 del; 12 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 galder at openjdk.org  Fri Sep 27 14:18:41 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 27 Sep 2024 14:18:41 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v2]
In-Reply-To: <idYp67bpPuveqjhqTLQOL2T1DotalBWz_m8iRayFsts=.f8334e0e-2061-458e-86f9-c009444748e6@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <l3QGajoAAxigBK5cfIYwdGPTKfbJJJLvnSYisn7O7x8=.15bd4030-3af2-4d3a-a013-8f9c392223f1@github.com>
 <MWiyM5dWze8wwUA4nKY5V-TiH98NO5qRlG3UcA3QbKw=.3c1c0d0f-de0c-485b-a5d0-f18c77aa32a4@github.com>
 <idYp67bpPuveqjhqTLQOL2T1DotalBWz_m8iRayFsts=.f8334e0e-2061-458e-86f9-c009444748e6@github.com>
Message-ID: <e44tmQMszeq9TEXML5pafR295iyNi2-aamqjMnGlSKg=.1f2d7893-63e6-4783-bb24-c95b2bd6fd84@github.com>

On Wed, 17 Jul 2024 22:48:04 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>>> The C2 changes look nice! I just added one comment here about style. It would also be good to add some IR tests checking that the intrinsic is creating `MaxL`/`MinL` nodes before macro expansion, and a microbenchmark to compare results.
>> 
>> Thanks for the review. +1 to the IR tests, I'll work on those.
>> 
>> Re: microbenchmark - what do you have exactly in mind? For vectorization performance there is `ReductionPerf` though it's not a microbenchmark per se. Do you want a microbenchmark for the performance of vectorized max/min long? For non-vectorization performance there is `MathBench`.
>> 
>> I would not expect performance differences in `MathBench` because the backend is still the same and this change really benefits vectorization. I've run the min/max long tests on darwin/aarch64 and linux/x64 and indeed I see no difference:
>> 
>> linux/x64
>> 
>> Benchmark          (seed)   Mode  Cnt        Score       Error   Units
>> MathBench.maxLong       0  thrpt    8  1464197.164 ? 27044.205  ops/ms # base
>> MathBench.minLong       0  thrpt    8  1469917.328 ? 25397.401  ops/ms # base
>> MathBench.maxLong       0  thrpt    8  1469615.250 ? 17950.429  ops/ms # patched
>> MathBench.minLong       0  thrpt    8  1456290.514 ? 44455.727  ops/ms # patched
>> 
>> 
>> darwin/aarch64
>> 
>> Benchmark          (seed)   Mode  Cnt        Score        Error   Units
>> MathBench.maxLong       0  thrpt    8  1739341.447 ? 210983.444  ops/ms # base
>> MathBench.minLong       0  thrpt    8  1659547.649 ? 260554.159  ops/ms # base
>> MathBench.maxLong       0  thrpt    8  1660449.074 ? 254534.725  ops/ms # patched
>> MathBench.minLong       0  thrpt    8  1729728.021 ?  16327.575  ops/ms # patched
>
>> Do you want a microbenchmark for the performance of vectorized max/min long?
> 
> Yeah, I think a simple benchmark that tests for long min/max vectorization and reduction would be good. I worry that checking performance manually like in `ReductionPerf` can lead to harder to interpret results than with a microbenchmark, especially with vm warmup ? Thanks for looking into this!

Following the advice from @jaskarth I've worked on a JMH benchmark for this intrinsic.

The benchmarks are pretty straightforward, but the way the data is distributed in the arrays has been designed such that the branch percentage can be controlled. The code uses a random increment/decrement algorithm to distribute the data for testing max. To test min the values are negated. Controlling the branching is an important factor, because the IR/assembly C2 emits can vary depending on the branching characteristics.

First, the non-AVX512 results (only posting max results for brevity, same seen with min):


Benchmark                         (probability)   (size)  Mode  Cnt    Score   Error   Units
MinMaxLoopBench.longReductionMax             50   10000  thrpt    8  107.609 ? 0.149  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax             80   10000  thrpt    8  107.627 ? 0.150  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax            100   10000  thrpt    8  238.799 ? 5.028  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax             50   10000  thrpt    8  107.575 ? 0.088  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax             80   10000  thrpt    8  107.594 ? 0.072  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax            100   10000  thrpt    8  107.514 ? 0.067  ops/ms (non-AVX512, patch)


The only situation where this PR is a regression compared to current code is when the one of the branch side is always taken. Why is this? At 50% and 80%, the base code uses cmovlq, but for 100% uses cmp+jump (the branch is for the uncommon trap). The intrinsic the patch adds means that a MinL/MaxL node is always used, and through the macro expansion that always transforms to cmovlq.

Next, the AVX-512 results (note that the results were taken in different machines, so the non-AVX-512 and AVX-512 numbers cannot be compared):


Benchmark                         (probability)  (size)   Mode  Cnt    Score   Error   Units
MinMaxLoopBench.longReductionMax             50   10000  thrpt    8  492.327 ? 0.106  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax             80   10000  thrpt    8  492.515 ? 0.044  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax            100   10000  thrpt    8  232.861 ? 5.859  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax             50   10000  thrpt    8  492.563 ? 0.452  ops/ms (AVX512, patch)
MinMaxLoopBench.longReductionMax             80   10000  thrpt    8  492.478 ? 0.105  ops/ms (AVX512, patch)
MinMaxLoopBench.longReductionMax            100   10000  thrpt    8  492.365 ? 0.220  ops/ms (AVX512, patch)


Here we see the same thing as in non-AVX512 systems but the other way around. For the base JDK, at 50-80% the CmpL+Bool gets converted into a CMoveL, and via `CMoveNode::Ideal_minmax` it gets converted to MinL/MaxL nodes, so it behaves just like the patched version. At 100% base adds a cmp+jump (for the uncommon trap branch) and because of flow control vectorization is not applied. The patched version behaves the same way regardless of the branch probability.

For completeness, here are the numbers from ~longLoopMax~, which tests vectorization of min/max without reduction on AVX-512. The pattern is the same:


Benchmark                         (probability)  (size)   Mode  Cnt    Score   Error   Units
MinMaxLoopBench.longLoopMax                  50   10000  thrpt    8   66.959 ? 0.426  ops/ms (AVX512, base)
MinMaxLoopBench.longLoopMax                  80   10000  thrpt    8   66.783 ? 0.342  ops/ms (AVX512, base)
MinMaxLoopBench.longLoopMax                 100   10000  thrpt    8   55.923 ? 0.390  ops/ms (AVX512, base)
MinMaxLoopBench.longLoopMax                  50   10000  thrpt    8   67.044 ? 0.535  ops/ms (AVX512, patch)
MinMaxLoopBench.longLoopMax                  80   10000  thrpt    8   66.600 ? 0.176  ops/ms (AVX512, patch)
MinMaxLoopBench.longLoopMax                 100   10000  thrpt    8   66.672 ? 0.205  ops/ms (AVX512, patch)


Finally, note that the reduction benchmarks only use one array to compute the value. Coming up with a random increment algorithm such that the combination of multiple array values would be higher/lower than the previous one was quite complex.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2379386872

From galder at openjdk.org  Fri Sep 27 14:21:57 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 27 Sep 2024 14:21:57 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@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 incrementally with three additional commits since the last revision:

 - Revert "Implement cmovL as a jump+mov branch"
   
   This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
 - Revert "Switch movl to movq"
   
   This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
 - Revert "Fix format of assembly for the movl to movq switch"
   
   This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/28778c84..16ae2a33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 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 galder at openjdk.org  Fri Sep 27 14:24:39 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 27 Sep 2024 14:24:39 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <qTdG5Vdh9CcEjh9S5tkqJRPuxHG6UA4lKFbzVQeEY5I=.a18d1627-9da3-46b7-a099-b257ddf867d7@github.com>

On Fri, 27 Sep 2024 14:21:57 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 three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

Reverted the ad changes, those are not related to this PR. While exploring the differences in performance between base and the patched version, I wondered why the cmov version was slower than the branch one. As part of that investigation I played around with modifying the ad file to make cmov emit a branch instead. The details of this can be found in https://bugs.openjdk.org/browse/JDK-8340206

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2379401009

From galder at openjdk.org  Fri Sep 27 14:40:37 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 27 Sep 2024 14:40:37 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <D7lazOTwH0mn8Rz6Wef4i6XdmlJDandySqQMq7drVqU=.d1e21ee6-e250-41a8-9bdc-ddfca496756d@github.com>

On Fri, 27 Sep 2024 14:21:57 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 three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

The numbers in https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872 might have been obtained with the ad changes included in them. I'll re-run the benchmarks again (in about ~2 weeks time) and post the results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2379434675

From duke at openjdk.org  Fri Sep 27 14:41:42 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 27 Sep 2024 14:41:42 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v5]
In-Reply-To: <9idRX4b22kj-n7LiVJnOsl64iEYsLLK4KIKBj6cMhSg=.c4924ce5-a054-42dc-a54e-9b9953f75690@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <LhVMelBYUcCdwYRS9AwkSq-_vXLB0-VgtNFncKyMRUE=.53c74f9a-23d5-44fe-ae00-b02df531fe65@github.com>
 <X-OV_514Yt8NxyYC6L7tZ8REylodFbjGW6C0fkfc794=.462f6fbd-62c9-47a3-a238-97300ecedce0@github.com>
 <O6j2cUnr1-x1TSCZwP3-8IewJYBxFlHiexGCMS3kEu0=.009d4221-8319-4486-8799-d7ff5d769e66@github.com>
 <Wo0s8NU66pV_TyPvz3lEQ0JOGf1CnYkOG4Vm9OhK-y0=.d6156ac5-0e85-43bb-a270-e45af3c8c154@github.com>
 <9idRX4b22kj-n7LiVJnOsl64iEYsLLK4KIKBj6cMhSg=.c4924ce5-a054-42dc-a54e-9b9953f75690@github.com>
Message-ID: <wRh79ceVMB-PdAvHs8jizYXRjfJvewkr9sgM1ejFs08=.e5898c58-8561-478e-8c90-5c75bf9bf262@github.com>

On Tue, 3 Sep 2024 16:50:26 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> > It would be nice to see some benchmarks where it gives performance benefits.
>>> 
>>> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe there the benefits are more visible...
>> 
>> "maybe"????
>> So, you don't have proof that this PR gives any performance benefits.
>> I don't think we have to make an optimization for the sake of optimizations.
>
> @kuksenko It's not only for the sake of optimization, but to make the code more clear and consistent with the implementation of `BigInteger.shiftLeft()`.

> @fabioromano1 Do you plan to work for more systematic tests, as discussed [above](https://github.com/openjdk/jdk/pull/20008#discussion_r1756784216)?

@rgiulietti Surely they would be useful, but I think it's reasonable to retain that the code is already correct, since it has been revised and it is based on solid logic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2379435774

From duke at openjdk.org  Fri Sep 27 14:41:36 2024
From: duke at openjdk.org (sbgoog)
Date: Fri, 27 Sep 2024 14:41:36 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
Message-ID: <_QHNRpif4d0UrV7tNmLtlnM4qXRuksJjQVxtCVRxdnM=.c82f512d-abd9-44c5-92ed-955e16b7f64f@github.com>

On Tue, 10 Sep 2024 16:37:11 GMT, sbgoog <duke at openjdk.org> wrote:

> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

This PR needs another reviewer. Is there someone that can have a look at it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20938#issuecomment-2379437283

From rgiulietti at openjdk.org  Fri Sep 27 15:25:39 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Sep 2024 15:25:39 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v11]
In-Reply-To: <Zz3KUZecTtgEfPZPqIPnz-S1E1JqsK3-hMkXLTtLHts=.27ec73b3-9376-41d8-9d6b-d6e2637feba7@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <Zz3KUZecTtgEfPZPqIPnz-S1E1JqsK3-hMkXLTtLHts=.27ec73b3-9376-41d8-9d6b-d6e2637feba7@github.com>
Message-ID: <5ZHQBql0i7lc2jHjVjhW-GcxM27X7MOeitZo6YW7zMs=.c13e056a-83fb-46b7-9852-29938703c7c8@github.com>

On Thu, 12 Sep 2024 20:49:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep parameters' name consistence

The tests must all pass before the code is integrated. Thus, the main purpose of retaining them in the repo is not to check the _current_ code, but to detect possible regressions when evolving it in the future.

Before having a final review, could you please merge `master` branch into yours?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2379536067

From bpb at openjdk.org  Fri Sep 27 15:50:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 27 Sep 2024 15:50:35 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <_QHNRpif4d0UrV7tNmLtlnM4qXRuksJjQVxtCVRxdnM=.c82f512d-abd9-44c5-92ed-955e16b7f64f@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <_QHNRpif4d0UrV7tNmLtlnM4qXRuksJjQVxtCVRxdnM=.c82f512d-abd9-44c5-92ed-955e16b7f64f@github.com>
Message-ID: <JQJOPk_COn0MeoErw35vwkHvpyfjVV4MWCtqTEnJ3Lk=.acb32800-7dcc-4c68-95c4-3eacd31c2b00@github.com>

On Fri, 27 Sep 2024 14:38:56 GMT, sbgoog <duke at openjdk.org> wrote:

> This PR needs another reviewer. Is there someone that can have a look at it?

@djelinski ? @jaikiran ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20938#issuecomment-2379585126

From naoto at openjdk.org  Fri Sep 27 15:55:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Sep 2024 15:55:42 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v6]
In-Reply-To: <kI0j0PN7ZTKY71ZbhRMOPigZtfdSRM_c_Pf3OIe12dI=.bfb690e1-1fb0-4023-b7de-d43874c5af8f@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <kI0j0PN7ZTKY71ZbhRMOPigZtfdSRM_c_Pf3OIe12dI=.bfb690e1-1fb0-4023-b7de-d43874c5af8f@github.com>
Message-ID: <Y8-45DIdDTurpKDXBBH977T70dqzfyhIhHlKsqDchb8=.b4f51630-6abd-4287-be5e-9a474b4ad8b1@github.com>

On Thu, 26 Sep 2024 17:24:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore ParseUtil_6380332.java test

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21096#pullrequestreview-2334108070

From bpb at openjdk.org  Fri Sep 27 16:12:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 27 Sep 2024 16:12:09 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream constructor
 specification
Message-ID: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>

Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."

-------------

Commit messages:
 - 8340229: Improve opening sentence of FileInputStream constructor specification

Changes: https://git.openjdk.org/jdk/pull/21223/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340229
  Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21223/head:pull/21223

PR: https://git.openjdk.org/jdk/pull/21223

From lancea at openjdk.org  Fri Sep 27 16:20:42 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Sep 2024 16:20:42 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
Message-ID: <gg44tmr78tyzTtrOE6W_BSxDdhQq0JfPeYFwVgHpaow=.fbfbdcf9-6af0-4275-baf4-c86af88cf7c2@github.com>

On Wed, 25 Sep 2024 16:22:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
>> 
>> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
>> 
>> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
>> 
>> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
>> 
>> Testing:
>> 
>> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
>> 
>> The `ZipFileOpen` benchmark seems neutral to this change.
>
> Eirik Bj?rsn?s 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 zipfile-endhdr
>  - Merge branch 'master' into zipfile-endhdr
>  - Do not include the END header when reading the CEN section

Overall, I think the changes are OK.   Please give it until Monday before integrating

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20905#pullrequestreview-2334154820

From duke at openjdk.org  Fri Sep 27 16:32:46 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 27 Sep 2024 16:32:46 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
Message-ID: <IBPRSJacXVJjxgovUgkDfw-OgSaclkbZBzT1xGPJGck=.ff42f857-2727-4f19-888b-055415162a17@github.com>

On Thu, 26 Sep 2024 08:16:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Updated copyright years
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
>    #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
>  - Merge branch 'master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/Opcode.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Annotation.java
>    #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
>    #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
>    #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I?wish?that the?concrete `PoolEntry`?subtypes had?`of(?)` factory?methods which?would create?instances using?the?`TemporaryConstantPool`, as?I?find?it?necessary to?create `PoolEntry`?instances in?contexts where?a?`ConstantPoolBuilder` is?not?easily?available (and?`ConstantPoolBuilder.of()` is?relatively?expensive when?creating a?one?off `PoolEntry`?instance) and?the?current `TemporaryConstantPool`?implementation doesn?t?support all?the?creation?methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2379656905

From galder at openjdk.org  Fri Sep 27 16:53:47 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 27 Sep 2024 16:53:47 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <2F2rvBSpHjpMXu40xa2hUUqWQYJJihO7mvXD73OCqKQ=.4cf78e1b-6d7a-4188-888d-f901fcf338cc@github.com>

On Fri, 27 Sep 2024 14:21:57 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 three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

Failure seems related to the patch, I'll look at it when I re-execute the benchmarks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2379688866

From ccheung at openjdk.org  Fri Sep 27 17:36:45 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 27 Sep 2024 17:36:45 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v5]
In-Reply-To: <BgVpitlVG7D3NB8EN9zFseK3sI3tRd4gaJN8zCDHCNE=.45974ca7-e145-402a-a777-faac0a92f959@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <nLhPjQbCLgZW2eNpwkeTwp0StAxDBhb_u8Y3HRaukmE=.86c9ae91-ddce-4493-a888-665f8f7f6589@github.com>
 <BgVpitlVG7D3NB8EN9zFseK3sI3tRd4gaJN8zCDHCNE=.45974ca7-e145-402a-a777-faac0a92f959@github.com>
Message-ID: <o6S9TSoG0TcbTj6eHK8fY76lP96hOhxGhKhu0GMxRrw=.33bdca74-6166-4dc8-bd9f-41d1af1e33df@github.com>

On Fri, 27 Sep 2024 11:11:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you remember why resetArchivedStates resets the resource cache? I would expected it to be cleared for all class loaders.
> 

I think it is because `resourceCache` is a `SoftReference` and it will fail the check in `JavaClasses::is_supported_for_archiving()`.

> Rather than putting something specific to the app class loader here then maybe it should be renamed and have resetArchivedStates call it, e.g.
> 
> ```
>     void resetArchivedStates(boolean all) {
>         ucp = null;
>         resourceCache = null;
>         if (all) {
>             moduleToReader.clear();
>         }
>     }
> ```

Under `if(all)`, we also need to do `setClassPath(null)`.
If I understand your suggestion correctly, in `BuiltinClassLoader`:

    private void resetArchivedStates() {
        resetArchivedStates(false);
    }


In `ClassLoaders.AppClassLoader`:

        private void resetArchivedStates() {
            resetArchivedStates(true);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1778944555

From aph at openjdk.org  Fri Sep 27 17:44:36 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 27 Sep 2024 17:44:36 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <e44tmQMszeq9TEXML5pafR295iyNi2-aamqjMnGlSKg=.1f2d7893-63e6-4783-bb24-c95b2bd6fd84@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <l3QGajoAAxigBK5cfIYwdGPTKfbJJJLvnSYisn7O7x8=.15bd4030-3af2-4d3a-a013-8f9c392223f1@github.com>
 <MWiyM5dWze8wwUA4nKY5V-TiH98NO5qRlG3UcA3QbKw=.3c1c0d0f-de0c-485b-a5d0-f18c77aa32a4@github.com>
 <idYp67bpPuveqjhqTLQOL2T1DotalBWz_m8iRayFsts=.f8334e0e-2061-458e-86f9-c009444748e6@github.com>
 <e44tmQMszeq9TEXML5pafR295iyNi2-aamqjMnGlSKg=.1f2d7893-63e6-4783-bb24-c95b2bd6fd84@github.com>
Message-ID: <qfgUY-4kPQG6byTjuP2Tse2lCPMnm3uMTBkguh3aL7Q=.1f03c9e0-2ed3-42e3-bbb6-57fe312bb6d9@github.com>

On Fri, 27 Sep 2024 14:15:04 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> The only situation where this PR is a regression compared to current code is when the one of the branch side is always taken.

Bear in mind that's quite common. It's not very unusual to clip a range with something equivalent to  `x = min(max(x, lowest), highest)`. What does benchmarking that look like, when all the `x` are within that range?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2379768983

From kvn at openjdk.org  Fri Sep 27 17:47:37 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 27 Sep 2024 17:47:37 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
Message-ID: <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>

On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [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:
> 
>   Amend the test case for guaranteing it works under different compilation regimes

Is ZGC affected by this? I see only G1 and Shenandoah changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2379772205

From henryjen at openjdk.org  Fri Sep 27 18:03:14 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 27 Sep 2024 18:03:14 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v3]
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <HvB3n3NzkjFR2uY4TxwxZGwd8ZzsrK2voEI-Q-3QKhM=.307efa67-8944-4e5c-81ab-3ab603b7672c@github.com>

> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
> 
> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
> 
> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
> 
> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
> 
> So we make this build in advance, and use a static array for values referred more than once.
> 
> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Missing from last commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21022/files
  - new: https://git.openjdk.org/jdk/pull/21022/files/ffce5eba..858703ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21022/head:pull/21022

PR: https://git.openjdk.org/jdk/pull/21022

From jlu at openjdk.org  Fri Sep 27 18:08:54 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Sep 2024 18:08:54 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v7]
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>

> Please review this PR which removes usages of Applet within the corelibs tests.
> 
> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
> 
> The following files were removed,
> 
> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>   - Test runner is no longer an Applet, so not needed
> - test/jdk/java/net/Socket/SocketImplTest.java
>   - An old Applet test missing Jtreg tags.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  revert bugID update to tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21096/files
  - new: https://git.openjdk.org/jdk/pull/21096/files/c90218e9..5b6bd624

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21096&range=05-06

  Stats: 9 lines in 9 files changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21096/head:pull/21096

PR: https://git.openjdk.org/jdk/pull/21096

From djelinski at openjdk.org  Fri Sep 27 18:49:38 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Sep 2024 18:49:38 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
Message-ID: <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>

On Tue, 10 Sep 2024 16:37:11 GMT, sbgoog <duke at openjdk.org> wrote:

> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 961:

> 959:             } catch(InterruptedException e) {
> 960:                 checkLockFile0ErrorCode(errorCode);
> 961:                 // Don't lose the interrupt unless we throw.

Why should we lose the interrupted status if we throw a SecurityException? It doesn't look right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1779019030

From duke at openjdk.org  Fri Sep 27 18:52:21 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 27 Sep 2024 18:52:21 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v12]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <7jNipsaoQt7llWAEXXTxOb_DZF4xQH2xWZt-YXx40bI=.f48a1405-5abe-4c72-9478-622a6ae01d10@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
 - Added path-targeted tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/09c13c5a..f2c8f35b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=10-11

  Stats: 56 lines in 1 file changed: 54 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From duke at openjdk.org  Fri Sep 27 18:56:00 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 27 Sep 2024 18:56:00 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v13]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <oXITlpiKNLOufjSqTAohni2cR3EeIzg69bS6tbQSuSg=.ad051b1d-3752-456c-8420-57705bfce5cb@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 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:

 - Merge branch 'openjdk:master' into patchLeftShift
 - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
 - Keep parameters' name consistence
 - Added path-targeted tests
 - Some code clarifications
 - Use supported annotation by jtreg in tests
 - Revision tests changes
 - Merge branch 'patchLeftShift' of https://github.com/fabioromano1/jdk into patchLeftShift
 - Merge branch 'openjdk:master' into patchLeftShift
 - Removed redundant code
 - ... and 8 more: https://git.openjdk.org/jdk/compare/27d5eb79...9473d9be

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/f2c8f35b..9473d9be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=11-12

  Stats: 183399 lines in 1428 files changed: 165938 ins; 9977 del; 7484 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From shade at openjdk.org  Fri Sep 27 19:00:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 19:00:39 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>
Message-ID: <rcGTOJcKY3ZAscPyEi3G5zKbPXRdHnJqibX5fiP4Elw=.8347be15-1ae3-4125-9f72-e230d2018a1a@github.com>

On Fri, 27 Sep 2024 17:44:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Is ZGC affected by this? I see only G1 and Shenandoah changes.

Good question.

ZGC expands the GC barriers late. This is why the IR test configuration that tests ZGC shows the same result as with other collectors: no additional fluff in IR. I would not expect we need anything else in late expansion for ZGC for Reference.clear, but maybe I am tired and cannot see it. Can you confirm this is fine, @fisk?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2379881102

From kvn at openjdk.org  Fri Sep 27 19:20:39 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 27 Sep 2024 19:20:39 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
Message-ID: <e5Cqg35Tk4LGZOdEhDx0UponI35AP39e_pqVij1VJyk=.30f09fc4-d58b-4e87-b5d5-d4adcc1e307e@github.com>

On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [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:
> 
>   Amend the test case for guaranteing it works under different compilation regimes

There is coming JEP for later G1 barriers expansion similar to ZGC. Will you still need this intrinsic after it? I assume Shenandoah will follow G1 later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2379910959

From duke at openjdk.org  Fri Sep 27 20:40:39 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 27 Sep 2024 20:40:39 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v2]
In-Reply-To: <MBFNBCeBpUUQJlhJV6ot_BAu8gRoNLLLegac0SWUsF8=.d1402333-ccc7-4690-b98f-b470f273c696@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
 <MBFNBCeBpUUQJlhJV6ot_BAu8gRoNLLLegac0SWUsF8=.d1402333-ccc7-4690-b98f-b470f273c696@github.com>
Message-ID: <jeXAb2jpgg2Cg8s6axZtzq-_sxGpBAX7Ul_J7JgydKk=.3305de6b-867c-49b9-9acc-113497dc03db@github.com>

On Fri, 30 Aug 2024 18:12:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

This is hopefully an uncontroversial change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20796#issuecomment-2380014780

From ccheung at openjdk.org  Fri Sep 27 22:44:05 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 27 Sep 2024 22:44:05 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v6]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <cnxReQSMXtfrI-GHoP018Lj_AlwQ_XBKjKkWCky05v0=.68711973-5d39-4de8-8fb8-1575cc004df5@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @AlanBateman comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/d96d78f8..3da4f9f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=04-05

  Stats: 12 lines in 2 files changed: 4 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From ccheung at openjdk.org  Fri Sep 27 23:05:31 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 27 Sep 2024 23:05:31 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v7]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <UhSwKDpbUnN3wBOQ0jf80OLPPsBqnFehD2WVSo6doNw=.8f57f727-cfc2-49ee-baf6-9f69404fd401@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - fix merge error
 - Merge branch 'master' into 8328313-FMG-module-path
 - @AlanBateman comments
 - @iklam comments
 - fix indentation
 - trailing whitespace
 - comments from David, Alan, and Ioi
 - 8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time

-------------

Changes: https://git.openjdk.org/jdk/pull/21048/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21048&range=06
  Stats: 525 lines in 19 files changed: 480 ins; 2 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

PR: https://git.openjdk.org/jdk/pull/21048

From kbarrett at openjdk.org  Fri Sep 27 23:56:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 27 Sep 2024 23:56:37 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
Message-ID: <lzbKsjK3JtjBSgMhnNnb_IMEHd86sJV0sPtRbWk5BN8=.60cc23a8-e846-481b-979f-8cd3ba4e18e7@github.com>

On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [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:
> 
>   Amend the test case for guaranteing it works under different compilation regimes

Changes requested by kbarrett (Reviewer).

src/java.base/share/classes/java/lang/ref/Reference.java line 420:

> 418:     /* Implementation of clear(), also used by enqueue().  A simple
> 419:      * assignment of the referent field won't do for some garbage
> 420:      * collectors.

Description of clear0 is rendered stale by this change.  The first sentence is no longer true, since it's now
clearImpl that has that role.  The second sentence probably ought to also be moved into the description of
clearImpl.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2334816850
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1779311136

From darcy at openjdk.org  Sat Sep 28 00:58:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 28 Sep 2024 00:58:40 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes"
In-Reply-To: <3hO_xQd_OMxjCSOVPsfXyLjHLaImY8WPz0TTHP1csGs=.639490ec-b4eb-4c38-99b4-c7e8811a5b56@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <3hO_xQd_OMxjCSOVPsfXyLjHLaImY8WPz0TTHP1csGs=.639490ec-b4eb-4c38-99b4-c7e8811a5b56@github.com>
Message-ID: <8wJetPBWF_1L6BnBKkVc_tkARxXmsm9MQ6IcaZemR50=.04613db9-7231-49fe-8f70-99351a2eeb0d@github.com>

On Fri, 27 Sep 2024 09:18:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."
>
> src/java.base/share/classes/java/lang/package-info.java line 36:
> 
>> 34:  * The <dfn>{@index "wrapper classes"}</dfn> {@link Boolean},
>> 35:  * {@link Character}, {@link Short}, {@link Integer}, {@link Long}, {@link Float},
>> 36:  * and {@link Double} serve this purpose.  An object of type {@code
> 
> Somehow, `Byte` is missing from that list. To be fair, it had been missing before this PR.

Good catch. After Byte is added, all 8 wrapper classes are present and accounted for.

> src/java.base/share/classes/java/lang/package-info.java line 63:
> 
>> 61:  * security policies.
>> 62:  *
>> 63:  * <p>Class {@link Throwable} encompasses objects that may be thrown
> 
> We already have a link to `Class` in this doc comment. This one can stay `{@code Class}`, which might be easier to read.

Isn't that the first reference to "Throwable" and the only link?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1779326113
PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1779326500

From darcy at openjdk.org  Sat Sep 28 01:26:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 28 Sep 2024 01:26:21 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v2]
In-Reply-To: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
Message-ID: <r3jXJ0wIJ5jcbSzXxPxRFTvgL7kEoK39CtFTAeYQGQI=.be68a829-855e-4164-81df-61cb44cb2029@github.com>

> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

Joe Darcy 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:

 - Respond to review feedback; completed planned work.
 - Merge branch 'master' into JDK-8341064
 - JDK-8341064: Define archor point and index term for "wrapper classes"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21215/files
  - new: https://git.openjdk.org/jdk/pull/21215/files/ada19264..bf53c4c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=00-01

  Stats: 700 lines in 45 files changed: 553 ins; 27 del; 120 mod
  Patch: https://git.openjdk.org/jdk/pull/21215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21215/head:pull/21215

PR: https://git.openjdk.org/jdk/pull/21215

From jpai at openjdk.org  Sat Sep 28 06:53:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 06:53:34 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
Message-ID: <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>

On Fri, 27 Sep 2024 16:06:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."

Do you think, as part of this PR, we should also revisit some of the javadoc in the `java.io.FileOutputStream` class which too has several mentions of "connection"?

src/java.base/share/classes/java/io/FileInputStream.java line 118:

> 116:     /**
> 117:      * Creates a {@code FileInputStream} to read from an existing file
> 118:      * named by the {@code File} object {@code file}.

Hello Brian, should be perhaps reword this as "... to read from an existing file represented by the {@code file}." This would almost match what we state for the constructor which takes the `FileDescriptor` instance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21223#issuecomment-2380434852
PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1779379540

From duke at openjdk.org  Sat Sep 28 07:00:36 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Sat, 28 Sep 2024 07:00:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>

On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword doce

I came with a new batch of weird layouts

`

        {
            // invalid after merge but logically valid
            Linker linker = Linker.nativeLinker();
            var padding = MemoryLayout.paddingLayout(1);
            var sequence = MemoryLayout.sequenceLayout(3, padding);
            var struct = MemoryLayout.structLayout(JAVA_BYTE, sequence, JAVA_INT);
            var fd = FunctionDescriptor.of(struct, struct, struct);
            linker.downcallHandle(fd);
        }

        {
            Linker linker = Linker.nativeLinker();
            var padding1 = MemoryLayout.paddingLayout(1);
            var padding2 = MemoryLayout.paddingLayout(2).withByteAlignment(2);
            var struct = MemoryLayout.structLayout(JAVA_BYTE, padding1, padding2, JAVA_INT);
            var fd = FunctionDescriptor.of(struct, struct, struct);
            linker.downcallHandle(fd);
        }

        {
            Linker linker = Linker.nativeLinker();
            var struct16 = MemoryLayout.structLayout(JAVA_LONG, JAVA_LONG);
            var padding16 = MemoryLayout.paddingLayout(16).withByteAlignment(16);
            var union = MemoryLayout.unionLayout(struct16, padding16);
            var fd = FunctionDescriptor.of(union, union, union);
            linker.downcallHandle(fd);
        }

        {
            Linker linker = Linker.nativeLinker();
            var struct32 = MemoryLayout.structLayout(MemoryLayout.sequenceLayout(4, JAVA_LONG));
            var padding1 = MemoryLayout.paddingLayout(1);
            var padding2 = MemoryLayout.paddingLayout(2).withByteAlignment(2);
            var padding4 = MemoryLayout.paddingLayout(4).withByteAlignment(4);
            var padding8 = MemoryLayout.paddingLayout(8).withByteAlignment(8);
            var padding16 = MemoryLayout.paddingLayout(16).withByteAlignment(16);
            var padding32 = MemoryLayout.paddingLayout(32).withByteAlignment(32);
            var union = MemoryLayout.unionLayout(struct32, padding32);
            var struct = MemoryLayout.structLayout(JAVA_BYTE, padding1, padding2, padding4, padding8, padding16, union);
            var fd = FunctionDescriptor.of(struct, struct, struct);
            linker.downcallHandle(fd);
        }
`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2380451924

From duke at openjdk.org  Sat Sep 28 07:30:18 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 28 Sep 2024 07:30:18 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v14]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <aa8JkQApakZQtCKIZV6zZNoYbDZWwj_hMk0I8fdjHK4=.27f12c47-6931-4222-b8dd-c6728b8b888c@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Small correction to ensure n > leadingZeros && nBits > leadingZeros

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/9473d9be..8ace0757

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=12-13

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008

From prappo at openjdk.org  Sat Sep 28 09:36:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 28 Sep 2024 09:36:35 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v2]
In-Reply-To: <8wJetPBWF_1L6BnBKkVc_tkARxXmsm9MQ6IcaZemR50=.04613db9-7231-49fe-8f70-99351a2eeb0d@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <3hO_xQd_OMxjCSOVPsfXyLjHLaImY8WPz0TTHP1csGs=.639490ec-b4eb-4c38-99b4-c7e8811a5b56@github.com>
 <8wJetPBWF_1L6BnBKkVc_tkARxXmsm9MQ6IcaZemR50=.04613db9-7231-49fe-8f70-99351a2eeb0d@github.com>
Message-ID: <8kI0PFZxBgqB3FGUNJylBwbC461T2Iy8rSWvSFO-x_Y=.3d8aaf2d-e67a-46a1-bcef-5ad0668d129d@github.com>

On Sat, 28 Sep 2024 00:56:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/package-info.java line 63:
>> 
>>> 61:  * security policies.
>>> 62:  *
>>> 63:  * <p>Class {@link Throwable} encompasses objects that may be thrown
>> 
>> We already have a link to `Class` in this doc comment. This one can stay `{@code Class}`, which might be easier to read.
>
> Isn't that the first reference to "Throwable" and the only link?

Sorry, I sloppily positioned my previous comment. It's about `Class` not `Throwable`. `@link` to `Class` appears on L29-30 and L46.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1779453015

From jpai at openjdk.org  Sat Sep 28 13:25:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 13:25:39 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
Message-ID: <9t08-mLwNe7GFHQCsa4vPpiEkqyJc2wJp1aoP6ZncBk=.b22bab4c-efc1-45be-a9ff-44a628b9a1ef@github.com>

On Wed, 25 Sep 2024 16:22:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
>> 
>> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
>> 
>> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
>> 
>> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
>> 
>> Testing:
>> 
>> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
>> 
>> The `ZipFileOpen` benchmark seems neutral to this change.
>
> Eirik Bj?rsn?s 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 zipfile-endhdr
>  - Merge branch 'master' into zipfile-endhdr
>  - Do not include the END header when reading the CEN section

src/java.base/share/classes/java/util/zip/ZipFile.java line 1184:

> 1182:         private static final int[] EMPTY_META_VERSIONS = new int[0];
> 1183:         // CEN size is limited to the maximum array size in the JDK
> 1184:         private static final int MAX_CEN_SIZE = Integer.MAX_VALUE - 2;

Hello Eirik, (at least) a couple of other places in the JDK (like the `jdk.internal.util.ArraysSupport.SOFT_MAX_ARRAY_LENGTH` and `java.io.InputStream.MAX_BUFFER_SIZE`) use `Integer.MAX_VALUE - 8` as the maximum supported array size. To be consistent, we should use that same here. In fact, `jdk.internal.util.ArraysSupport.SOFT_MAX_ARRAY_LENGTH` is a public field in the JDK and we could just reference it here as follows:


// CEN size is limited to the maximum array size in the JDK
private static final int MAX_CEN_SIZE = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 71:

> 69:     private static final int ENDOFF = ZipFile.ENDOFF; // Offset of CEN offset field within ENDHDR
> 70:     // Maximum allowed CEN size allowed by ZipFile
> 71:     private static int MAX_CEN_SIZE = Integer.MAX_VALUE - 2;

Same comment here, we should make this `Integer.MAX_VALUE - 8`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20905#discussion_r1779484365
PR Review Comment: https://git.openjdk.org/jdk/pull/20905#discussion_r1779484503

From swen at openjdk.org  Sat Sep 28 13:54:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 28 Sep 2024 13:54:05 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
Message-ID: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>

A small optimization to reduce the write operations of trimAndCompress

-------------

Commit messages:
 - optimize trimAndCompress

Changes: https://git.openjdk.org/jdk/pull/21227/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21227&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341136
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21227/head:pull/21227

PR: https://git.openjdk.org/jdk/pull/21227

From jpai at openjdk.org  Sat Sep 28 13:55:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 13:55:45 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
Message-ID: <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>

On Fri, 27 Sep 2024 01:41:17 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 316:
>> 
>>> 314: main.help.opt.extract.keep-old-files=\
>>> 315: \  -k, --keep-old-files       Do not overwrite existing files.\n\
>>> 316: \                             In particular, if a file appears more than once in an\n\
>> 
>> In addition, we need to update the help to clarify -x. --extract behavior that it will overwrite by default.
>> 
>> Here is the verbiage from tar to give you a start
>> 
>> ` -x      Extract to disk from the archive.  If a file with the same name appears more than
>>              once in the archive, each copy will be extracted, with later copies overwriting
>>              (replacing) earlier copies.  The long option form is --extract.`
>
> Updated.

Hello Henry, I think this `-k` option help text would need a slight modification. Right now it states that if a file appears more than once in an archive, then this setting this flag will not overwrite the earlier copies. In reality, it doesn't matter how many times the file appears in the archive - even if it appears just once, and if the file is being extracted into a directory which already has the same named file at that path, then this `-k` flag will not overwrite that existing file.

So I think we should reword it to talk about its behaviour in context of some file already existing in the destination directory where the jar contents are being extracted. 

I wonder if we should make a mention that we don't do any case sensitive checks for the existence of the file in the destination directory and instead we use filesystem API to check for existence (which depending on the filesystem may be case insensitive, like macosx).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779492170

From jpai at openjdk.org  Sat Sep 28 14:11:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:11:34 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <6OAyg7t0GLznmc8NQaepLkn-Jz4j83YVYJVLNEeIKb0=.eff09bc1-c232-4045-9c46-d8d7144665ac@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/ExtractFilesTest.java line 168:

> 166: 
> 167:     private Stream<Path> mkpath(String... args) {
> 168:         return Arrays.stream(args).map(d -> Paths.get(".", d.split("/")));

For newer code usages, like this one, it's recommended to use `Path.of(...)` instead of `Paths.get(...)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779494948

From jpai at openjdk.org  Sat Sep 28 14:14:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:14:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <Mqr5-E4_z-rRUQ8adRmq7xz7VEQdRxpcR4FoN99b24s=.62f49497-844b-41c5-b7fd-b01133a3d1d3@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/ExtractFilesTest.java line 207:

> 205:         try {
> 206:             var p = Paths.get(".", path.split("/"));
> 207:             return String.join(nl, Files.readAllLines(p));

Do you think this could be simplified to `return Files.readString(p)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779496134

From jpai at openjdk.org  Sat Sep 28 14:35:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:35:39 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/ExtractFilesTest.java line 236:

> 234:         PrintStream err = new PrintStream(baes);
> 235:         PrintStream saveErr = System.err;
> 236:         System.setErr(err);

Given that we are updating the runtime level state, I think we should use `/othervm` in this test's definition to avoid any interference with other parts of the runtime.

test/jdk/tools/jar/ExtractFilesTest.java line 238:

> 236:         System.setErr(err);
> 237:         int rc = JAR_TOOL.run(out, err, cmdline.split(" +"));
> 238:         System.setErr(saveErr);

Doing a

try {
int rc = JAR_TOOL.run(out, err, cmdline.split(" +"));
}finally {
System.setErr(saveErr);
}

would be safer.

test/jdk/tools/jar/ExtractFilesTest.java line 241:

> 239:         if (rc != 0) {
> 240:             String s = baes.toString();
> 241:             if (s.startsWith("java.util.zip.ZipException: duplicate entry: ")) {

This method runs any arbitrary `jar` "command". Is there any significance why we are checking for a "duplicate entry" in the exception message? Maybe we could just remove this entire if block and just throw a `new IOException(s)`? As far as I can see in this test, we don't do any exception type checks on the thrown exception from this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779499876
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779500135
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779501074

From jpai at openjdk.org  Sat Sep 28 14:39:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 28 Sep 2024 14:39:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <chgru-eK0dp3Ry1ReWcafs638yzkBtuyPK3MmjTeSBI=.f5e457a2-0a1b-4e87-98a0-03a3d276367b@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

test/jdk/tools/jar/MultipleManifestTest.java line 67:

> 65: 
> 66: @TestInstance(Lifecycle.PER_CLASS)
> 67: @TestMethodOrder(MethodName.class)

Is the use of these annotations intentional? Especially the method ordering?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1779501649

From darcy at openjdk.org  Sat Sep 28 15:01:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 28 Sep 2024 15:01:11 GMT
Subject: RFR: 8341100: Add index entries for terms used in java.lang.Class
Message-ID: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>

Small update to java.lang.Class docs.

I didn't add an index item for "hidden classes" since the indexing mechanism picks up the section titles.

-------------

Commit messages:
 - Refine changes.
 - Merge branch 'master' into JDK-8341100
 - JDK-8341100: Add index entries for terms used in java.lang.Class

Changes: https://git.openjdk.org/jdk/pull/21241/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21241&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341100
  Stats: 9 lines in 1 file changed: 2 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21241/head:pull/21241

PR: https://git.openjdk.org/jdk/pull/21241

From darcy at openjdk.org  Sat Sep 28 15:02:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 28 Sep 2024 15:02:50 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
Message-ID: <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>

> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21215/files
  - new: https://git.openjdk.org/jdk/pull/21215/files/bf53c4c2..d1cf8b75

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21215/head:pull/21215

PR: https://git.openjdk.org/jdk/pull/21215

From markus at headcrashing.eu  Sat Sep 28 16:15:54 2024
From: markus at headcrashing.eu (Markus Karg)
Date: Sat, 28 Sep 2024 18:15:54 +0200
Subject: Proposal for new public class: java.io.CharSequenceReader
Message-ID: <000001db11c1$b22a7990$167f6cb0$@eu>

Dear Sirs,

 

for performance reasons, hereby I like to propose the new public class
java.io.CharSequenceReader. Before sharing a pull request, I'd kindly like
to request for comments.

 

Since Java 1.1 we have the StringReader class. Since Java 1.4 we have the
CharSequence class. StringBuilder, StringBuffer and CharBuffer are
first-class implementations of it in the JDK, and there might exist
third-party implementations of non-String character streams. Until today,
however, we do not have a Reader for CharSequences, but need to go costly
detours.

 

To process non-String character streams, the typical detour today is to turn
a CharSequence into a temporary String (hence duplicating its full
contents), which needs time and memory (and eventually GC), for the sole
sake of being processable by a StringReader. As StringReader is
synchronized, each single access is synthetically slowed down. In many cases
the synchronization has no use at all, as in real-world applications, least
Readers are actually accessed concurrently. As a result, today the major
benefit of StringBuilder over StringBuffer (being non-synchronized) vanishes
as soon as a StringReader is used to access it. This means, "new
StringReader(stringBuffer.toString());" imposes slower performance than
essentially needed, in two ways: toString, synchronized.

 

In an attempt to improve performance of this rather typical use case, I like
to contribute a pull request providing the new public class
java.io.CharSequenceReader. My idea is to mostly copy the existing code of
StringReader, but wrap CharSequence instead of String; then strip
synchronization; then add optimized access for the String, StringBuffer and
StringBuilder implementations (in the sense of ::getChars(char[], int, int)
to prevent a char-by-char loop in these cases). The idea mostly is covered
by Apache Commons IO's CharSequenceReader, which nicely serves as a PoC:
https://github.com/apache/commons-io/blob/master/src/main/java/org/apache/co
mmons/io/input/CharSequenceReader.java.

 

Alternatives:

- Applications could use Apache Commons IO's CharSequenceReader. As it is an
open-source third-party dependency, some authors might not be allowed to use
it, or may not want to carry this additional burden just for the sake of
this single performance improvement. In addition, this library is not very
actively maintained; its Java baseline still is Java 8. There is no
commercial support.

- Applications could write their own Reader implementation. Given the
assumption that this is a rather common use case, this imposes unjustified
additional work for the authors of thousands of applications. It is hard to
justify why there is a StringReader but not a CharSequenceReader.

- Instead of writing a new CharSequenceReader class we could slightly modify
StringReader, so it accepts CharSequences (not only Strings). This does not
remove the synchronization overhead unless we decide to remove the
synchronization from StringReader's implementation, and it would be
confusing / surprising (in the negative sense) that a class named
"StringReader" actually is a "CharSequenceReader".

 

Options:

- Instead of adding special cases for
"String/StringBuilder/StringBuffer::getChars()", we could add
"getChars(char[], int, int)" as a new default method to the CharSequence
interface, essentially providing a char-by-char loop for all CharSequence
implementations not already having an optimized getChars method. This makes
the implementation of CharSequenceReader simpler, as not "switch over
instanceof" is needed to benefit from optimized "getChars" implementations.

- Once we have CharSequenceReader, we could replace the full implementation
of StringReader by synchronized calls to CharSequenceReader. This would
reduce duplicate code.

 

Kindly requesting comments.

-Markus Karg

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240928/ecb55e47/attachment-0001.htm>

From duke at openjdk.org  Sat Sep 28 17:18:34 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sat, 28 Sep 2024 17:18:34 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
Message-ID: <UEuRuY59-owvlGrBsFzj1HXsWF3LTVgbiHFiAbybFio=.2efc8f37-589a-4efe-92c4-490b350834f6@github.com>

On Fri, 27 Sep 2024 17:05:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the write operations of trimAndCompress

We can improve performance by avoiding repeated array access in the loop. Instead of accessing types[i] multiple times, we cache it in a local variable. Here's the optimized version
`for (int i = 0; i < count; i++) {
    Type current = types[i]; 
    if (!current.isCategory2_2nd()) {
        if (compressed != i) {
            types[compressed] = current;
        }
        compressed++;
    }
}
` This reduces overhead from multiple array lookups.

-------------

Changes requested by abdelhak-zaaim at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/21227#pullrequestreview-2335379912

From duke at openjdk.org  Sat Sep 28 17:53:34 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sat, 28 Sep 2024 17:53:34 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
Message-ID: <I_0zejpq6NXrGzNyri7zFp24-DEtEV2fBHh-nzrSpBI=.01c61f4d-7bea-4bc4-bf91-1de94d0d478a@github.com>

On Fri, 27 Sep 2024 17:05:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the write operations of trimAndCompress

I think there's no significant performance impact with this change, or it's negligible, because the condition is replaced by an assignment. While the condition check would affect every loop cycle, the overhead is minimal compared to the direct assignment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21227#issuecomment-2380847455

From ecki at zusammenkunft.net  Sat Sep 28 17:59:41 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 28 Sep 2024 19:59:41 +0200 (CEST)
Subject: Proposal for new public class: java.io.CharSequenceReader
In-Reply-To: <000001db11c1$b22a7990$167f6cb0$@eu>
References: <000001db11c1$b22a7990$167f6cb0$@eu>
Message-ID: <20240928175941.DC23B662B5B@dd33810.kasserver.com>




Markus Karg schrieb am 28.09.2024 18:15 (GMT +02:00):
> Dear Sirs,
> for performance reasons, hereby I like to propose the new public class
> java.io.CharSequenceReader
> 
I like the idea and missed it in the past.

while we are at it, also support a char[] constructor (since this
char[] does not implement CharSequence)

You hinted at it, but just to make it explicit, user mode implementations
cant do the needed optimizations to avoid the char[] clone.

Gruss
Bernd
> 



From liach at openjdk.org  Sat Sep 28 18:52:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 28 Sep 2024 18:52:36 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
Message-ID: <6xJLAN3vfUc6VUkNONEIpA5dgEes0gicfuBthf5qDQI=.233f645f-8fd7-486f-8291-b22a82f48a56@github.com>

On Fri, 27 Sep 2024 17:05:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the write operations of trimAndCompress

Does this bring a speed up in the interpreter or compiled code like C2? Indeed the category 2 long/double primitive types appear rarely, and the majority of methods won't need to change their stacks in compression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21227#issuecomment-2380863491

From liach at openjdk.org  Sat Sep 28 19:20:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 28 Sep 2024 19:20:37 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v2]
In-Reply-To: <MBFNBCeBpUUQJlhJV6ot_BAu8gRoNLLLegac0SWUsF8=.d1402333-ccc7-4690-b98f-b470f273c696@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
 <MBFNBCeBpUUQJlhJV6ot_BAu8gRoNLLLegac0SWUsF8=.d1402333-ccc7-4690-b98f-b470f273c696@github.com>
Message-ID: <iPlBWSi_cDXeZIMh6OBGx42tHPZ-ZNyzwgTEbyybFSo=.6eb621cd-014d-4239-a7ea-7283e4d667f1@github.com>

On Fri, 30 Aug 2024 18:12:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Also since this is just adding links, I don't think this needs a CSR (compare to the similar cleanup Joe Darcy is doing to the `java.lang` and math content).

src/java.base/share/classes/java/lang/classfile/Attributes.java line 251:

> 249:      * {@return Attribute mapper for the {@code ConstantValue} attribute}
> 250:      * @since 23
> 251:      * @see java.lang.classfile.constantpool.ConstantPoolBuilder#constantValueEntry(java.lang.constant.ConstantDesc)

Suggestion:


Redundant here. People can probably follow the link on the type argument.

src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 481:

> 479:      *
> 480:      * @param c the constant
> 481:      * @see java.lang.classfile.Attributes#constantValue()

Suggestion:

     * @see ConstantValueEntry#constantValue()

as it's the reverse operation of this.

src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java line 46:

> 44:      * {@link Long}, {@link Float}, {@link Double}, or {@link String}.
> 45:      *
> 46:      * @see java.lang.classfile.Attributes#constantValue()

I wish you can:
1. Add a link on the `{@code ConstantValue}` in class main javadoc so it's like `{@link ConstantValueAttribute ConstantValue}` or `{@link Attributes#constantValue ConstantValue}`
2. Change the `@see` link to `ConstantPoolBuilder#constantValueEntry` as that pairs up with this method.

Suggestion:

     * @see ConstantPoolBuilder#constantValueEntry(ClassDesc)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20796#issuecomment-2380870658
PR Review Comment: https://git.openjdk.org/jdk/pull/20796#discussion_r1779740219
PR Review Comment: https://git.openjdk.org/jdk/pull/20796#discussion_r1779740185
PR Review Comment: https://git.openjdk.org/jdk/pull/20796#discussion_r1779739929

From liach at openjdk.org  Sat Sep 28 19:25:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 28 Sep 2024 19:25:38 GMT
Subject: RFR: 8341100: Add index entries for terms used in java.lang.Class
In-Reply-To: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
References: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
Message-ID: <m_H7ZTsEcQ7xfginIFYLxI3-b5BKmn-T6CmhLJmVTxM=.86994572-db43-4594-bb12-09f4f83fd3c4@github.com>

On Sat, 28 Sep 2024 14:56:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small update to java.lang.Class docs.
> 
> I didn't add an index item for "hidden classes" since the indexing mechanism picks up the section titles.

Confirmed that searching for "hidden class" finds the "Hidden Classes" section in JDK 23 API docs.

src/java.base/share/classes/java/lang/Class.java line 144:

> 142:  * It is also possible to get the {@code Class} object for a named
> 143:  * class or interface (or for {@code void}) using a <dfn>class literal</dfn>
> 144:  * (JLS  {@jls 15.8.2}).

Suggestion:

 * (JLS {@jls 15.8.2}).

Also, the preexisting description of "class or interface" as represented by `java.lang.Class` is incorrect; it also represents primitive types, including void, and array types. But this problem exists in the first-sentence summary as well, so I believe we should fix it in another RFE.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21241#pullrequestreview-2335402043
PR Review Comment: https://git.openjdk.org/jdk/pull/21241#discussion_r1779740777

From prappo at openjdk.org  Sat Sep 28 21:32:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 28 Sep 2024 21:32:37 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
Message-ID: <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>

On Sat, 28 Sep 2024 15:02:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/package-info.java line 34:

> 32:  * <p>Frequently it is necessary to represent a value of primitive
> 33:  * type as if it were an object.<a id="wrapperClasses"></a> The
> 34:  * <dfn>{@index "wrapper classes"}</dfn> {@link Boolean}, {@link

I can see that JDK uses the `<a name="xyz"></a>` pattern in many locations. That is, an empty `a` tag which has the `name` attribute. You use the `id` attribute. JDK uses such pattern too, but only in a few locations.

Regardless of the details, I was wondering if instead of adding a new tag with an attribute, we should just add an attribute to an existing tag.

`dfn` seems to be designed exactly for that [^1][^2]. Additionally, keeping tags to a minimum might not worsen readability as much:

    <dfn id="wrapperClasses">{@index "wrapper classes"}</dfn>

@jonathan-gibbons, @hns, thoughts?

[^1]: https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-dfn-element
[^2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dfn

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1779774865

From prappo at openjdk.org  Sat Sep 28 21:36:34 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 28 Sep 2024 21:36:34 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
Message-ID: <LF_qfurozSiA4txIkYqqHpZM6f-qnPNrG1qdzAjw-_4=.eabf1a18-55c2-42c1-bc33-f25ec7825013@github.com>

On Sat, 28 Sep 2024 15:02:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Thanks for doing this; looks good.

I'm interested in learning what others think of that `<a>`/`<dfn>` issue I commented about.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21215#pullrequestreview-2335447358

From liach at openjdk.org  Sat Sep 28 21:47:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 28 Sep 2024 21:47:34 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
Message-ID: <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>

On Sat, 28 Sep 2024 21:30:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/lang/package-info.java line 34:
> 
>> 32:  * <p>Frequently it is necessary to represent a value of primitive
>> 33:  * type as if it were an object.<a id="wrapperClasses"></a> The
>> 34:  * <dfn>{@index "wrapper classes"}</dfn> {@link Boolean}, {@link
> 
> I can see that JDK uses the `<a name="xyz"></a>` pattern in many locations. That is, an empty `a` tag which has the `name` attribute. You use the `id` attribute. JDK uses such pattern too, but only in a few locations.
> 
> Regardless of the details, I was wondering if instead of adding a new tag with an attribute, we should just add an attribute to an existing tag.
> 
> `dfn` seems to be designed exactly for that [^1][^2]. Additionally, keeping tags to a minimum might not worsen readability as much:
> 
>     <dfn id="wrapperClasses">{@index "wrapper classes"}</dfn>
> 
> @jonathan-gibbons, @hns, thoughts?
> 
> [^1]: https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-dfn-element
> [^2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dfn

Agree; I have recommedned consolidating id property into h2 without an extra a tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1779795860

From swen at openjdk.org  Sun Sep 29 02:17:29 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 29 Sep 2024 02:17:29 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder
Message-ID: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>

Some DirectCodeBuilder related optimizations to improve startup and running performance:
1. Merge calls, merge writeU1 and writeU2 into writeU3
2. Merge calls, merge writeU1 and writeIndex operations
3. Directly use writeU1 instead of writeBytecode
4. Rewrite the implementation of load and store

-------------

Commit messages:
 - remove DirectCodeBuilder::writeLocalVar
 - optimize DirectCodeBuilder

Changes: https://git.openjdk.org/jdk/pull/21243/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341141
  Stats: 489 lines in 6 files changed: 297 ins; 35 del; 157 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Sun Sep 29 02:19:42 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 29 Sep 2024 02:19:42 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
Message-ID: <N3TMknblUn7iNPeU_-xpBNmQRzBds9oynz4SqnBnwxM=.fc81799b-6f45-4cee-bc7d-2b100fa8ace6@github.com>

On Fri, 27 Sep 2024 17:05:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the write operations of trimAndCompress

I saw trimAndCompress in the flame graph of the profile, so I made this optimization. Avoiding write operations here is a very small optimization and will not have a significant improvement. I don?t have Benchmark performance numbers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21227#issuecomment-2381072287

From swen at openjdk.org  Sun Sep 29 02:33:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 29 Sep 2024 02:33:44 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <UEuRuY59-owvlGrBsFzj1HXsWF3LTVgbiHFiAbybFio=.2efc8f37-589a-4efe-92c4-490b350834f6@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
 <UEuRuY59-owvlGrBsFzj1HXsWF3LTVgbiHFiAbybFio=.2efc8f37-589a-4efe-92c4-490b350834f6@github.com>
Message-ID: <c9G1Sv5TRJZeRl_sF2j7exKyloHdV2pYOc_20Z2rjmQ=.a74dbf60-725b-4eb8-bd87-fd22783f73fb@github.com>

On Sat, 28 Sep 2024 17:15:43 GMT, Abdelhak Zaaim <duke at openjdk.org> wrote:

> We can improve performance by avoiding repeated array access in the loop. Instead of accessing types[i] multiple times, we cache it in a local variable. Here's the optimized version `for (int i = 0; i < count; i++) { Type current = types[i]; if (!current.isCategory2_2nd()) { if (compressed != i) { types[compressed] = current; } compressed++; } } ` This reduces overhead from multiple array lookups.

This will add one more store and one more load operation in the loop when there is no isCategory2_2nd. The classfile is optimized to be faster at startup and work better in interpreted mode or C1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21227#issuecomment-2381076305

From iklam at openjdk.org  Sun Sep 29 04:15:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 29 Sep 2024 04:15:41 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
Message-ID: <2TjFLEwheCeUXfKrmZW_wJ_oCB7BNoknhhecGaMC2g0=.6469d724-cd72-42df-a89d-5ffb7ab995b9@github.com>

On Thu, 26 Sep 2024 00:45:20 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderExt.cpp line 162:
>> 
>>> 160:         int n = os::snprintf(full_name, full_name_len, "%s%s%s", path, os::file_separator(), file_name);
>>> 161:         assert((size_t)n == full_name_len - 1, "Unexpected number of characters in string");
>>> 162:         module_paths->append(full_name);
>> 
>> Can this case be handled: --module-path=dir
>> 
>> - Dump time :  dir contains only mod1.jar
>> - Run time :  dir contains only mod1.jar and mod2.jmod
>
> It should work because the jmod file won't be added to the `module_paths`.

In my scenario, will the FMG be used? If so, the program won't be able to load the code in mod2.jmod, so the behavior will be wrong. Could you add a test case for this?

>> src/hotspot/share/runtime/arguments.cpp line 347:
>> 
>>> 345:     }
>>> 346:   }
>>> 347:   return false;
>> 
>> Can this be simplified to `return (strcmp(key, MODULE_PROPERTY_PREFIX PATH) == 0)`?
>
> I'm not sure. Is your suggest equivalent to:
>   `return (strcmp(key, "jdk.module.path"));`

Yes, the C++ compiler will automatically concatenate `MODULE_PROPERTY_PREFIX PATH` into a single string.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1779902553
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1779902689

From jbhateja at openjdk.org  Sun Sep 29 04:26:19 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 29 Sep 2024 04:26:19 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86 VPMULUDQ
 instruction
Message-ID: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>

This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
  

       MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
       MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
       MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
       MulL   ( And  SRC1,  0xFFFFFFFF) (URShift SRC2 , 32)



 A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.

If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
 
VPMULUDQ instruction performs unsigned multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.

Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
 

Sierra Forest :-
============
Baseline:-
Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms

With Optimization:-
Benchmark                                 (SIZE)   Mode  Cnt     Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  1299.407          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2   504.995          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2   327.544          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2   160.963          ops/ms

Granite Rapids:-
=============
Baseline:-
Benchmark                                 (SIZE)   Mode  Cnt     Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  2279.099          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  1148.609          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2   570.848          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2   268.872          ops/ms

With Optimization:-
Benchmark                                 (SIZE)   Mode  Cnt     Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  2612.484          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  1308.187          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2   653.375          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2   316.182          ops/ms


Kindly review and share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

Changes: https://git.openjdk.org/jdk/pull/21244/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341137
  Stats: 355 lines in 12 files changed: 343 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21244/head:pull/21244

PR: https://git.openjdk.org/jdk/pull/21244

From iklam at openjdk.org  Sun Sep 29 04:28:40 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 29 Sep 2024 04:28:40 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
Message-ID: <8zmMK9osKaE2aA051AjovRF3ilTWLZhsSQKTgans7QQ=.87813411-03bb-4b52-af61-8e7595c794e2@github.com>

On Thu, 26 Sep 2024 00:45:48 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 1092:
>> 
>>> 1090:     void resetArchivedStatesForAppClassLoader() {
>>> 1091:         setClassPath(null);
>>> 1092:         if (!moduleToReader.isEmpty()) moduleToReader.clear();
>> 
>> Suggestion:
>> 
>>         if (!moduleToReader.isEmpty()) {
>>             moduleToReader.clear();
>>         }
>> 
>> 
>> Also, do we need to do the same thing for the platform loader as well?
>
> Added braces.
> The `setClassPath(null)` used to be in `ClassLoaders.AppClassLoader`. Based on investigations so far, the clearing of the `moduleToReader` map is required only for `AppClassLoader`.

Why does it need to clear `moduleToReader` only for app loader and not for platform loader? Is it because the `moduleToReader` for the app loader may contain reference to jar files that indirectly references some file system objects?

Since moduleToReader is just a cache, I think it's better to always clear it for both loaders. Also, the logic can be moved into BuiltinClassLoader: 


class BuiltinClassLoader {
        ....
        private void resetArchivedStates() {
            ucp = null;
            resourceCache = null;
            setClassPath(null);  // AppClassLoader will initialize this again at runtime.
            moduleToReader.clear();
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1779903867

From alanb at openjdk.org  Sun Sep 29 06:46:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 29 Sep 2024 06:46:34 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <8zmMK9osKaE2aA051AjovRF3ilTWLZhsSQKTgans7QQ=.87813411-03bb-4b52-af61-8e7595c794e2@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
 <8zmMK9osKaE2aA051AjovRF3ilTWLZhsSQKTgans7QQ=.87813411-03bb-4b52-af61-8e7595c794e2@github.com>
Message-ID: <JgKjpc7KozfFkpYHl8YpG3vp6GvVZKTP8ibD-9lkFrI=.864de45a-e859-42f2-9073-13d0043ade3d@github.com>

On Sun, 29 Sep 2024 04:23:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Added braces.
>> The `setClassPath(null)` used to be in `ClassLoaders.AppClassLoader`. Based on investigations so far, the clearing of the `moduleToReader` map is required only for `AppClassLoader`.
>
> Why does it need to clear `moduleToReader` only for app loader and not for platform loader? Is it because the `moduleToReader` for the app loader may contain reference to jar files that indirectly references some file system objects?
> 
> Since moduleToReader is just a cache, I think it's better to always clear it for both loaders. Also, the logic can be moved into BuiltinClassLoader: 
> 
> 
> class BuiltinClassLoader {
>         ....
>         private void resetArchivedStates() {
>             ucp = null;
>             resourceCache = null;
>             setClassPath(null);  // AppClassLoader will initialize this again at runtime.
>             moduleToReader.clear();
>         }

setClassPath(null) is the same as `ucp = null` but yes, keep it simple as otherwise there will be question each time there are changes. BuiltinClassPath should not include any code that is specific to the app class loader or the platform class loader as there are specific subclasses for that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1779923680

From alanb at openjdk.org  Sun Sep 29 07:03:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 29 Sep 2024 07:03:38 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
Message-ID: <cE6IQ71zuBvo79X18ra-2yeUXOTRlZW01GNk-7Ug1xc=.4bad2079-570f-4c55-903f-f2615a9a2c89@github.com>

On Fri, 27 Sep 2024 16:06:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."

src/java.base/share/classes/java/io/FileInputStream.java line 166:

> 164:     /**
> 165:      * Creates a {@code FileInputStream} to read from an existing file
> 166:      * represented by the {@code FileDescriptor} object {@code fdObj}.

I don't know if you meant to touch this constructor or not but I think it's okay to use "connected" here as this is creating a FIS to read bytes from whatever the file descriptor is connected to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1779926706

From swen at openjdk.org  Sun Sep 29 09:43:49 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 29 Sep 2024 09:43:49 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v2]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <1fZtTfga9K9w2bTPtkPJyAhGpPVRt7VXGOiPn35A_wk=.3c05bd27-1a1e-4de2-be1b-016e9535b376@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use array instead of ArrayList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/2c3d4f12..3cb16578

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=00-01

  Stats: 44 lines in 1 file changed: 25 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Sun Sep 29 10:50:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 29 Sep 2024 10:50:11 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v3]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <1vn6P_C3Q4XJEMTaYpIV92tjXuRU3_VofS0bJTYg_NE=.ff11908e-5b44-48c5-b044-4e9a1f7d677a@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/3cb16578..9e2e4db4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=01-02

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From openjdk at icemanx.nl  Sun Sep 29 11:05:00 2024
From: openjdk at icemanx.nl (Rob Spoor)
Date: Sun, 29 Sep 2024 13:05:00 +0200
Subject: Proposal for new public class: java.io.CharSequenceReader
In-Reply-To: <000001db11c1$b22a7990$167f6cb0$@eu>
References: <000001db11c1$b22a7990$167f6cb0$@eu>
Message-ID: <dcd91e16-db28-4889-86d9-31e0c3ba9c45@icemanx.nl>

On 28/09/2024 18:15, Markus Karg wrote:
> - Applications could use Apache Commons IO's CharSequenceReader. As it is an
> open-source third-party dependency, some authors might not be allowed to use
> it, or may not want to carry this additional burden just for the sake of
> this single performance improvement. In addition, this library is not very
> actively maintained; its Java baseline still is Java 8. There is no
> commercial support.

As someone who has provided some PRs for the project, I can tell you 
it's actively maintained. There have been 4 minor versions in 2023 and 2 
in 2024. It probably still targets Java 8 because that's still a 
maintained LTS version. The library is generic enough to be useful even 
on Java 8.
(The commercial support is a valid comment though.)

> - Instead of adding special cases for
> "String/StringBuilder/StringBuffer::getChars()", we could add
> "getChars(char[], int, int)" as a new default method to the CharSequence
> interface, essentially providing a char-by-char loop for all CharSequence
> implementations not already having an optimized getChars method. This makes
> the implementation of CharSequenceReader simpler, as not "switch over
> instanceof" is needed to benefit from optimized "getChars" implementations.

As the developer that added the if-statements using getChars for 
CharSequenceReader 5 years ago, I applaud this. In fact, I have already 
suggested this almost 4 years ago: 
https://mail.openjdk.org/pipermail/core-libs-dev/2020-November/071149.html. 
Unfortunately I can't find my changes anywhere so this would need to be 
rewritten.


Kind regards,

Rob

From swen at openjdk.org  Sun Sep 29 13:35:14 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 29 Sep 2024 13:35:14 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v4]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <EPO8PQtvAHRF6tEt9JkV8BIfj_53eTG9DPdlGCFi37k=.ef5a195f-e70c-47bd-a668-49cbe89e1817@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use array instead of ArrayList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/9e2e4db4..dab40af9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=02-03

  Stats: 27 lines in 1 file changed: 10 ins; 5 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From attila at openjdk.org  Sun Sep 29 17:50:09 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 29 Sep 2024 17:50:09 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting ArrayList
 sublists
Message-ID: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>

Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.

This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

-------------

Commit messages:
 - ConcurrentModificationException should not be thrown when sorting ArrayList subLists

Changes: https://git.openjdk.org/jdk/pull/21250/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21250&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340572
  Stats: 44 lines in 2 files changed: 43 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21250.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21250/head:pull/21250

PR: https://git.openjdk.org/jdk/pull/21250

From jjg at openjdk.org  Sun Sep 29 18:10:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sun, 29 Sep 2024 18:10:34 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
 <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
Message-ID: <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>

On Sat, 28 Sep 2024 21:45:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/package-info.java line 34:
>> 
>>> 32:  * <p>Frequently it is necessary to represent a value of primitive
>>> 33:  * type as if it were an object.<a id="wrapperClasses"></a> The
>>> 34:  * <dfn>{@index "wrapper classes"}</dfn> {@link Boolean}, {@link
>> 
>> I can see that JDK uses the `<a name="xyz"></a>` pattern in many locations. That is, an empty `a` tag which has the `name` attribute. You use the `id` attribute. JDK uses such pattern too, but only in a few locations.
>> 
>> Regardless of the details, I was wondering if instead of adding a new tag with an attribute, we should just add an attribute to an existing tag.
>> 
>> `dfn` seems to be designed exactly for that [^1][^2]. Additionally, keeping tags to a minimum might not worsen readability as much:
>> 
>>     <dfn id="wrapperClasses">{@index "wrapper classes"}</dfn>
>> 
>> @jonathan-gibbons, @hns, thoughts?
>> 
>> [^1]: https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-dfn-element
>> [^2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dfn
>
> Agree; I have recommedned consolidating id property into h2 without an extra a tag.

`<dfn>` is a semantic tag to indicate the defining instance of a term. It may be used by search engines, to improve their results.   When `<dfn>` is used as intended, it may be reasonable and convenient to put an `id` on the tag, to provide a link target for elsewhere in the documentation. It may also be convenient to add `id` to other locations, especially headers, but note that `javadoc` now does that automatically.

The usage of `<a name="...">` is a legacy usage from HTML 4, before the improved rules for `id` in HTML 5.  It would be a reasonable cleanup to move away from such tags, putting an equivalent `id` on either a replacement tag (such as `<span>`) or on an appropriate nearby tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1780100498

From redestad at openjdk.org  Sun Sep 29 18:36:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 29 Sep 2024 18:36:35 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v4]
In-Reply-To: <EPO8PQtvAHRF6tEt9JkV8BIfj_53eTG9DPdlGCFi37k=.ef5a195f-e70c-47bd-a668-49cbe89e1817@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <EPO8PQtvAHRF6tEt9JkV8BIfj_53eTG9DPdlGCFi37k=.ef5a195f-e70c-47bd-a668-49cbe89e1817@github.com>
Message-ID: <_imMacavvkRnFUMy2HfXlE0uvWmKomTFwtVEu1V4bIg=.da5eae95-b2c4-4c80-8ce5-b169e1e48117@github.com>

On Sun, 29 Sep 2024 13:35:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use array instead of ArrayList

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 115:

> 113: 
> 114:     @ForceInline
> 115:     public void writeU2(int x1, int x2) {

Perhaps a more descriptive name would be `writeU1U1` here, then `writeU1U2`, `writeU1U1U1` and `writeU2U2` for the next methods, respectively? Either way these methods will be a bit of an eye-sore, but let's at least iron out any ambiguities.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1780105574

From dholmes at openjdk.org  Sun Sep 29 21:52:33 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 29 Sep 2024 21:52:33 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
Message-ID: <aIxX6fMnCtQ9eQqUU1Ou32J1J_MgQ5gZUyej0PcRP5M=.fbbeab52-4033-405f-851b-13b0431cdbcc@github.com>

On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
> 
> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

Just an observation, but sorting is not defined as a "structural modification" but obviously would interfere with an active iterator. So the docs may need updating to include this aspect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2381622959

From dholmes at openjdk.org  Sun Sep 29 22:19:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 29 Sep 2024 22:19:35 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <O7XW4a3YxSJeLCtbLUJ73xeINN5P0m2MQMEPtbkhuNU=.05a00a08-6a49-42be-917c-4df8702f3f9b@github.com>

On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

`jni_md.h` is shipped as part of every JDK distribution - this change does NOT belong in that file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2381630944

From dholmes at openjdk.org  Sun Sep 29 22:25:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 29 Sep 2024 22:25:40 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
Message-ID: <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>

On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
> 
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
> 
> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
> 
> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
> 
> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
> 
> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
> 
> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
> 
> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent stores that initialize the newForm from being r...

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1882:

> 1880:                     assert (newForm.customized == null || newForm.customized == this);
> 1881:                     newForm.prepare(); // as in MethodHandle.<init>
> 1882:                     UNSAFE.putReferenceRelease(this, FORM_OFFSET, newForm); // properly publish newForm

A full-fence is a one-sided global synchronization action. A "release" store is one side of a two-sided synchronization action: where is the "load-acquire" that this pairs with?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1780191840

From liach at openjdk.org  Sun Sep 29 22:41:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 29 Sep 2024 22:41:39 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>
Message-ID: <BPXpziMnJ5abo68eNo6ClJH2c-eTDmJbT0ul71h_ysk=.0397a5ca-505e-469c-a6de-0574e6d58fe4@github.com>

On Sun, 29 Sep 2024 22:22:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When investigating an intermittent NPE with an Oracle internal test on AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by `MethodHandles::jump_to_lambda_form` when trying to load the `MemberName::method` field because the `MemberName` we retrieved from `LambdaForm::vmentry` is null:
>> 
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp#L141-L143
>> 
>> The JVM translates SIGSEGVs happening in method handle intrinsics to NPEs, assuming that they are implicit NPEs due to a null receiver:
>> https://github.com/openjdk/jdk/blob/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60/src/hotspot/share/runtime/sharedRuntime.cpp#L979-L982
>> 
>> After digging around in the MethodHandle implementation that I'm not too familiar with, I found this suspicious code in `MethodHandle::updateForm`:
>> https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1881-L1883
>> 
>> The `Unsafe.fullFence` was added by [JDK-8059877](https://bugs.openjdk.org/browse/JDK-8059877) and replaced a `// ISSUE: Should we have a memory fence here?` [comment](https://github.com/openjdk/jdk/commit/224c42ee4d4c3027d1f8f0d8b7ecf6646e9418c3#diff-5a4b2f817a4273eacf07f3ee24782c58c8ff474c6d790f72298e906837c5543aL1442). If the intention was to [prevent publishing a partially initialized object](https://wiki.sei.cmu.edu/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects), I think it was added to the wrong place (paging @iwanowww).
>> 
>> In the failing scenario, we concurrently trigger LambdaForm customization for a VarHandle invoker:
>> 
>> 	at java.base/java.lang.invoke.MethodHandle.updateForm(MethodHandle.java:1883)
>> 	at java.base/java.lang.invoke.MethodHandle.customize(MethodHandle.java:1856)
>> 	at java.base/java.lang.invoke.MethodHandle.maybeCustomize(MethodHandle.java:1846)
>> 	at java.base/java.lang.invoke.Invokers.maybeCustomize(Invokers.java:632)
>> 	at java.base/java.lang.invoke.Invokers.checkCustomized(Invokers.java:626)
>> 
>> The problem is that another thread can observe `newForm` which via the `MethodHandle::form` field before the store to `vmentry` in `prepare()` (see [here](https://github.com/openjdk/jdk/blob/36314a90c15e2ab2a9b32c2e471655c1b07d452c/src/java.base/share/classes/java/lang/invoke/LambdaForm.java#L821)) is visible and therefore observe null. We need a StoreStore barrier to prevent store...
>
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1882:
> 
>> 1880:                     assert (newForm.customized == null || newForm.customized == this);
>> 1881:                     newForm.prepare(); // as in MethodHandle.<init>
>> 1882:                     UNSAFE.putReferenceRelease(this, FORM_OFFSET, newForm); // properly publish newForm
> 
> A full-fence is a one-sided global synchronization action. A "release" store is one side of a two-sided synchronization action: where is the "load-acquire" that this pairs with?

The `form` field is a final field; thus, all reads to that field is a load-acquire. This load-load barrier is critical to ensure observing the correct, non-null `vmentry` field value if the updated form is observed.

Note that JIT compilation may constant-fold the preexisting form and ignore the updated form. This is still behaviorally identical, but usually the new form is more suitable for constant folding if JIT compilation can pick it up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1780194398

From liach at openjdk.org  Sun Sep 29 22:48:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 29 Sep 2024 22:48:35 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v4]
In-Reply-To: <EPO8PQtvAHRF6tEt9JkV8BIfj_53eTG9DPdlGCFi37k=.ef5a195f-e70c-47bd-a668-49cbe89e1817@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <EPO8PQtvAHRF6tEt9JkV8BIfj_53eTG9DPdlGCFi37k=.ef5a195f-e70c-47bd-a668-49cbe89e1817@github.com>
Message-ID: <jq3UP9GRYpEh1nZNWAmInunvFSCd0CR25ssUrd6P2aI=.21b61ad6-7eab-411a-a6a1-b1779a58455e@github.com>

On Sun, 29 Sep 2024 13:35:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use array instead of ArrayList

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 124:

> 122:     }
> 123: 
> 124:     public void writeU3(int u1, int u2) {

This one should be `writeU1U2` or `write12`. If people use this as "write u2 and write u1" the higher byte of 1st arg will be truncated incorrectly.

The other `writeU2` and `writeU3` already have 3 args so it's easy to assume that they drop the more significant bytes and only use the least significant byte of each argument.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 144:

> 142:     }
> 143: 
> 144:     public void writeU4(int x1, int x2) {

Since we are writing 2 u2 instead of 1 u4, we should call this `writeU2U2` or just `write22` (unsigned or signed are the same). Same concern for byte truncation.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 605:

> 603:                                      int count) {
> 604:         bytecodesBufWriter.writeIndex(opcode.bytecode(), ref);
> 605:         bytecodesBufWriter.writeU2(count << 8);

Suggestion:

        bytecodesBufWriter.writeU2(count, 0);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1779821432
PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1779821071
PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1779821719

From dholmes at openjdk.org  Sun Sep 29 23:55:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 29 Sep 2024 23:55:41 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <BPXpziMnJ5abo68eNo6ClJH2c-eTDmJbT0ul71h_ysk=.0397a5ca-505e-469c-a6de-0574e6d58fe4@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>
 <BPXpziMnJ5abo68eNo6ClJH2c-eTDmJbT0ul71h_ysk=.0397a5ca-505e-469c-a6de-0574e6d58fe4@github.com>
Message-ID: <3EiusEynJophkZit60FyWA03NXWVjgAoCwNlJfeTh7o=.17f73dc6-3ed9-4b9e-8748-265cd25d5ac5@github.com>

On Sun, 29 Sep 2024 22:39:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1882:
>> 
>>> 1880:                     assert (newForm.customized == null || newForm.customized == this);
>>> 1881:                     newForm.prepare(); // as in MethodHandle.<init>
>>> 1882:                     UNSAFE.putReferenceRelease(this, FORM_OFFSET, newForm); // properly publish newForm
>> 
>> A full-fence is a one-sided global synchronization action. A "release" store is one side of a two-sided synchronization action: where is the "load-acquire" that this pairs with?
>
> The `form` field is a final field; thus, all reads to that field is a load-acquire. This load-load barrier is critical to ensure observing the correct, non-null `vmentry` field value if the updated form is observed.
> 
> Note that JIT compilation may constant-fold the preexisting form and ignore the updated form. This is still behaviorally identical, but usually the new form is more suitable for constant folding if JIT compilation can pick it up.

That's not exactly how final fields are specified. It is hard to see here exactly what fields/objects are involved in this case. The final field semantics only provide load-acquire-like semantics if you dereference the final field after the freeze action in the constructor. And our use of Unsafe here means we are stepping outside any JLS guarantees anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1780208741

From swen at openjdk.org  Mon Sep 30 01:09:21 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 01:09:21 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v5]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <IAzWwxdgzlVvWK2n8OwYvvf-fwKWstdLjRoLJDmcbbk=.ac306223-ce80-47dd-9f8c-0510f48747dd@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @cl4es and @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/dab40af9..2ca81a37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=03-04

  Stats: 24 lines in 3 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From darcy at openjdk.org  Mon Sep 30 02:10:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 02:10:09 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v4]
In-Reply-To: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
Message-ID: <onnzZobI-N7udO15uj05bszuCGub-v-iUi4NWlzePE4=.1f786baf-7c1b-450f-adb2-08ea3f90e013@github.com>

> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21215/files
  - new: https://git.openjdk.org/jdk/pull/21215/files/d1cf8b75..94b92628

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21215&range=02-03

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21215/head:pull/21215

PR: https://git.openjdk.org/jdk/pull/21215

From darcy at openjdk.org  Mon Sep 30 02:10:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 02:10:09 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
 <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
 <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>
Message-ID: <QoGfFmZ-QdSDiaFJ5jl15mYke686RTSopmAuxNHTqdE=.54158994-56b6-4929-9423-17af80c1a55e@github.com>

On Sun, 29 Sep 2024 18:08:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Agree; I have recommedned consolidating id property into h2 without an extra a tag.
>
> `<dfn>` is a semantic tag to indicate the defining instance of a term. It may be used by search engines, to improve their results.   When `<dfn>` is used as intended, it may be reasonable and convenient to put an `id` on the tag, to provide a link target for elsewhere in the documentation. It may also be convenient to add `id` to other locations, especially headers, but note that `javadoc` now does that automatically.
> 
> The usage of `<a name="...">` is a legacy usage from HTML 4, before the improved rules for `id` in HTML 5.  It would be a reasonable cleanup to move away from such tags, putting an equivalent `id` on either a replacement tag (such as `<span>`) or on an appropriate nearby tag.

Thanks for the HTML tip; will add an id to the dfn tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1780318858

From darcy at openjdk.org  Mon Sep 30 02:18:17 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 02:18:17 GMT
Subject: RFR: 8341100: Add index entries for terms used in java.lang.Class
 [v2]
In-Reply-To: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
References: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
Message-ID: <_D7zdd9cOGvZE98jKER4JQPBgri86KzeEJZT8Y-t83Y=.a344bc78-3fd7-4f9d-8e21-3416412df2d3@github.com>

> Small update to java.lang.Class docs.
> 
> I didn't add an index item for "hidden classes" since the indexing mechanism picks up the section titles.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21241/files
  - new: https://git.openjdk.org/jdk/pull/21241/files/dbf830a9..9e93a865

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21241&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21241&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21241/head:pull/21241

PR: https://git.openjdk.org/jdk/pull/21241

From liach at openjdk.org  Mon Sep 30 02:44:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 02:44:42 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v4]
In-Reply-To: <onnzZobI-N7udO15uj05bszuCGub-v-iUi4NWlzePE4=.1f786baf-7c1b-450f-adb2-08ea3f90e013@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <onnzZobI-N7udO15uj05bszuCGub-v-iUi4NWlzePE4=.1f786baf-7c1b-450f-adb2-08ea3f90e013@github.com>
Message-ID: <ukV1Fqw4_00VxbW-on54qWuZb2E4Fcvb6R03jiuDgxo=.24299270-86ab-471b-af1f-acade5f06587@github.com>

On Mon, 30 Sep 2024 02:10:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21215#pullrequestreview-2336235926

From iklam at openjdk.org  Mon Sep 30 03:11:09 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 30 Sep 2024 03:11:09 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v6]
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <6MbJFWb56tFFlJYXkaJbvsEMKEJG14UUpNQkk5Uc5Ng=.7c8ed5c3-955f-496e-b259-1fa0a424a1ae@github.com>

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - @macarte comments
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
 - Fixed copyright dates
 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Fixed whitespaces
 - 8338017: Add AOT command-line flag aliases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20516/files
  - new: https://git.openjdk.org/jdk/pull/20516/files/7b0d6f8b..26df2d5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=04-05

  Stats: 12274 lines in 290 files changed: 9741 ins; 1521 del; 1012 mod
  Patch: https://git.openjdk.org/jdk/pull/20516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20516/head:pull/20516

PR: https://git.openjdk.org/jdk/pull/20516

From swen at openjdk.org  Mon Sep 30 04:12:52 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 04:12:52 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v6]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <dQnJOPRwRx-wtqbeFlPlN4rMNltCCsiWIqrv9QUKGV8=.fea2804a-bc91-4bbc-9471-09fe8df4b1a3@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with 53 additional commits since the last revision:

 - optimize writeBranch
 - Local var clean
 - 8340621: Open source several AWT List tests
   
   Reviewed-by: prr
 - 8340639: Open source few more AWT List tests
   
   Reviewed-by: prr
 - 8340560: Open Source several AWT/2D font and rendering tests
   
   Reviewed-by: kizune
 - 8340721: Clarify special case handling of unboxedType and getWildcardType
   
   Reviewed-by: prappo, mcimadamore
 - 8341101: [ARM32] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694
   
   Reviewed-by: shade
 - 8340404: CharsetProvider specification updates
   
   Reviewed-by: alanb, naoto
 - 8337679: Memset warning in src/hotspot/share/adlc/adlArena.cpp
   
   Reviewed-by: stefank, thartmann, jwaters
 - 8341059: Change Entrust TLS distrust date to November 12, 2024
   
   Reviewed-by: mullan
 - ... and 43 more: https://git.openjdk.org/jdk/compare/2ca81a37...d6c34593

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/2ca81a37..d6c34593

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=04-05

  Stats: 7940 lines in 183 files changed: 4934 ins; 1662 del; 1344 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Mon Sep 30 04:18:14 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 04:18:14 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v7]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <cn1pNaw7CyKizVf9h7giBlS07glKxXdiChI-GwliVmQ=.b69a1840-d0e4-4278-bf7c-5a87523d1958@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

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 60 additional commits since the last revision:

 - Merge branch 'master' into optim_direct_code_builder_202409
 - optimize writeBranch
 - Local var clean
 - 8340621: Open source several AWT List tests
   
   Reviewed-by: prr
 - 8340639: Open source few more AWT List tests
   
   Reviewed-by: prr
 - 8340560: Open Source several AWT/2D font and rendering tests
   
   Reviewed-by: kizune
 - 8340721: Clarify special case handling of unboxedType and getWildcardType
   
   Reviewed-by: prappo, mcimadamore
 - 8341101: [ARM32] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694
   
   Reviewed-by: shade
 - 8340404: CharsetProvider specification updates
   
   Reviewed-by: alanb, naoto
 - 8337679: Memset warning in src/hotspot/share/adlc/adlArena.cpp
   
   Reviewed-by: stefank, thartmann, jwaters
 - ... and 50 more: https://git.openjdk.org/jdk/compare/8ac2b68e...b69800dc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/d6c34593..b69800dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=05-06

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Mon Sep 30 04:31:13 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 04:31:13 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v8]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <v1BseVgIC_isl46HooxTCfJL1clnT2YizMhc9AG5O68=.2e29cb1d-3618-4f64-b564-3d0fbaebb1a0@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove jdkTreePrimitive & use new api

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/b69800dc..7b840194

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=06-07

  Stats: 51 lines in 1 file changed: 0 ins; 48 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From pminborg at openjdk.org  Mon Sep 30 06:15:38 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 30 Sep 2024 06:15:38 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <qfgUY-4kPQG6byTjuP2Tse2lCPMnm3uMTBkguh3aL7Q=.1f03c9e0-2ed3-42e3-bbb6-57fe312bb6d9@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <l3QGajoAAxigBK5cfIYwdGPTKfbJJJLvnSYisn7O7x8=.15bd4030-3af2-4d3a-a013-8f9c392223f1@github.com>
 <MWiyM5dWze8wwUA4nKY5V-TiH98NO5qRlG3UcA3QbKw=.3c1c0d0f-de0c-485b-a5d0-f18c77aa32a4@github.com>
 <idYp67bpPuveqjhqTLQOL2T1DotalBWz_m8iRayFsts=.f8334e0e-2061-458e-86f9-c009444748e6@github.com>
 <e44tmQMszeq9TEXML5pafR295iyNi2-aamqjMnGlSKg=.1f2d7893-63e6-4783-bb24-c95b2bd6fd84@github.com>
 <qfgUY-4kPQG6byTjuP2Tse2lCPMnm3uMTBkguh3aL7Q=.1f03c9e0-2ed3-42e3-bbb6-57fe312bb6d9@github.com>
Message-ID: <kHEk2q_4MDZ4Of17FiMBZZ7ogW16wpKjpjMpqYFeOFU=.5a0c7823-1980-4946-b6c8-38929597774c@github.com>

On Fri, 27 Sep 2024 17:42:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > The only situation where this PR is a regression compared to current code is when the one of the branch side is always taken.
> 
> Bear in mind that's quite common. It's not very unusual to clip a range with something equivalent to `x = min(max(x, lowest), highest)`. What does benchmarking that look like, when all the `x` are within that range?

In fact, the new `Math::clamp` methods do just this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2382197333

From swen at openjdk.org  Mon Sep 30 06:19:51 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 06:19:51 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v9]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <SQDrWcW6Bujir7pDIQDdU2zcZsBVoeSKX-WR3chxyM0=.5f2d8ed9-f79b-49b7-bb76-0ffce64fd00a@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize writeBranch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/7b840194..0b52b641

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=07-08

  Stats: 156 lines in 2 files changed: 133 ins; 13 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Mon Sep 30 06:48:07 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 06:48:07 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v10]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <KAikdSOcbJvG_NRkvTxmlaqMWxVBizxgMwATVPDNJCE=.b2fdef4c-f3c8-4a19-a5bf-661f4c5759d2@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize writeBranch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/0b52b641..3396e379

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=08-09

  Stats: 25 lines in 1 file changed: 3 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From alan.bateman at oracle.com  Mon Sep 30 07:07:10 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Sep 2024 08:07:10 +0100
Subject: Proposal for new public class: java.io.CharSequenceReader
In-Reply-To: <000001db11c1$b22a7990$167f6cb0$@eu>
References: <000001db11c1$b22a7990$167f6cb0$@eu>
Message-ID: <e3335540-7091-4eec-9f39-af8f2d709d4d@oracle.com>

On 28/09/2024 17:15, Markus Karg wrote:
> :
>
> Alternatives:
>
> - Applications could use Apache Commons IO's CharSequenceReader. As it 
> is an open-source third-party dependency, some authors might not be 
> allowed to use it, or may not want to carry this additional burden 
> just for the sake of this single performance improvement. In addition, 
> this library is not very actively maintained; its Java baseline still 
> is Java 8. There is no commercial support.
>
> - Applications could write their own Reader implementation. Given the 
> assumption that this is a rather common use case, this imposes 
> unjustified additional work for the authors of thousands of 
> applications. It is hard to justify why there is a StringReader but 
> not a CharSequenceReader.
>
> - Instead of writing a new CharSequenceReader class we could slightly 
> modify StringReader, so it accepts CharSequences (not only Strings). 
> This does not remove the synchronization overhead unless we decide to 
> remove the synchronization from StringReader's implementation, and it 
> would be confusing / surprising (in the negative sense) that a class 
> named "StringReader" actually is a "CharSequenceReader".
>
>

Add to your list to explore is a static factory method on Reader, look 
at Reader.nullReader. That would avoid exposing yet another very 
specific implementation class in the API. The specification of that 
method could say that is isn't safe for use by concurrent threads. That 
doesn't excuse you completely from thinking about concurrent use as 
Readers have a close method so you'll need to think about how close is 
specified for when it is called while another thread is reading chars 
from a custom CS.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240930/eaffd6c5/attachment.htm>

From jpai at openjdk.org  Mon Sep 30 08:09:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Sep 2024 08:09:07 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper
Message-ID: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@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.

-------------

Commit messages:
 - 8341184: Clean up the interaction between the launcher native code and the LauncherHelper

Changes: https://git.openjdk.org/jdk/pull/21256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341184
  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 prappo at openjdk.org  Mon Sep 30 09:05:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 30 Sep 2024 09:05:38 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v4]
In-Reply-To: <onnzZobI-N7udO15uj05bszuCGub-v-iUi4NWlzePE4=.1f786baf-7c1b-450f-adb2-08ea3f90e013@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <onnzZobI-N7udO15uj05bszuCGub-v-iUi4NWlzePE4=.1f786baf-7c1b-450f-adb2-08ea3f90e013@github.com>
Message-ID: <eVirWkwDOVhg5DT_QbQBy4ImbZnSaymhnYOamDrfx1U=.8952a2a7-5586-40a5-9cc0-4afbdeca3af5@github.com>

On Mon, 30 Sep 2024 02:10:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21215#pullrequestreview-2336828340

From eirbjo at openjdk.org  Mon Sep 30 09:27:11 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 30 Sep 2024 09:27:11 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v3]
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year for CenSizeTooLarge
 - Delegate MAX_CEN_SIZE to existing internal constant ArraysSupport.SOFT_MAX_ARRAY_LENGTH

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20905/files
  - new: https://git.openjdk.org/jdk/pull/20905/files/97ef7283..45c9c6ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20905&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20905&range=01-02

  Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20905/head:pull/20905

PR: https://git.openjdk.org/jdk/pull/20905

From redestad at openjdk.org  Mon Sep 30 09:27:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 30 Sep 2024 09:27:11 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v3]
In-Reply-To: <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>
Message-ID: <6d171Vi6E5BZXsF4nVB_Vp_fLSIDVfPOoTWpuvQeh3A=.456af3c1-f63e-4e18-ae11-c88168c6f688@github.com>

On Mon, 30 Sep 2024 09:24:22 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
>> 
>> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
>> 
>> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
>> 
>> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
>> 
>> Testing:
>> 
>> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
>> 
>> The `ZipFileOpen` benchmark seems neutral to this change.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year for CenSizeTooLarge
>  - Delegate MAX_CEN_SIZE to existing internal constant ArraysSupport.SOFT_MAX_ARRAY_LENGTH

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20905#pullrequestreview-2336869804

From eirbjo at openjdk.org  Mon Sep 30 09:27:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 30 Sep 2024 09:27:13 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v2]
In-Reply-To: <9t08-mLwNe7GFHQCsa4vPpiEkqyJc2wJp1aoP6ZncBk=.b22bab4c-efc1-45be-a9ff-44a628b9a1ef@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <xKudM7pA1oX1iuWPE4MNI6t7LkaKID8uGTcbt8Tkbs4=.aa74dfab-53c0-407a-bccb-daab4b07698f@github.com>
 <9t08-mLwNe7GFHQCsa4vPpiEkqyJc2wJp1aoP6ZncBk=.b22bab4c-efc1-45be-a9ff-44a628b9a1ef@github.com>
Message-ID: <FkeBGV_BiKWioRWHjMaHg00QUewVZ_mytpjbPOrH3N4=.6a1a4518-2556-4a59-bea8-96b8442dc7ac@github.com>

On Sat, 28 Sep 2024 13:20:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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 zipfile-endhdr
>>  - Merge branch 'master' into zipfile-endhdr
>>  - Do not include the END header when reading the CEN section
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1184:
> 
>> 1182:         private static final int[] EMPTY_META_VERSIONS = new int[0];
>> 1183:         // CEN size is limited to the maximum array size in the JDK
>> 1184:         private static final int MAX_CEN_SIZE = Integer.MAX_VALUE - 2;
> 
> Hello Eirik, (at least) a couple of other places in the JDK (like the `jdk.internal.util.ArraysSupport.SOFT_MAX_ARRAY_LENGTH` and `java.io.InputStream.MAX_BUFFER_SIZE`) use `Integer.MAX_VALUE - 8` as the maximum supported array size. To be consistent, we should use that same here. In fact, `jdk.internal.util.ArraysSupport.SOFT_MAX_ARRAY_LENGTH` is a public field in the JDK and we could just reference it here as follows:
> 
> 
> // CEN size is limited to the maximum array size in the JDK
> private static final int MAX_CEN_SIZE = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;

Thanks, I like that we can delegate  this constant value out of `java.util.zip` where indeed it looks somewhat arbitrary.

I also update the tests `EndOfCenValidation` and `CenSizeTooLarge` to use the same constant, adding `@modules` jtreg tags as needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20905#discussion_r1780737509

From asotona at openjdk.org  Mon Sep 30 09:27:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 30 Sep 2024 09:27:39 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v6]
In-Reply-To: <IBPRSJacXVJjxgovUgkDfw-OgSaclkbZBzT1xGPJGck=.ff42f857-2727-4f19-888b-055415162a17@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <70Qi28tPoRbjxF4D4OXLKmrGNDIHFPpGWTRb_h7Iam0=.ea993ce7-29a0-4bf6-9824-3dc17bd1bc6b@github.com>
 <IBPRSJacXVJjxgovUgkDfw-OgSaclkbZBzT1xGPJGck=.ff42f857-2727-4f19-888b-055415162a17@github.com>
Message-ID: <QPdSqODYrQQQUNjsPKuxoOmi8z9J1mFyvXlSQ5pbbZk=.c0eabecf-25d7-4e56-974f-47e7aa34b3bf@github.com>

On Fri, 27 Sep 2024 16:29:30 GMT, ExE Boss <duke at openjdk.org> wrote:

> I?wish?that the?concrete `PoolEntry`?subtypes had?`of(?)` factory?methods...

Please forward the proposal on clasfile-api-dev mailing list, where it can be discussed. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2382597723

From jpai at openjdk.org  Mon Sep 30 09:33:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Sep 2024 09:33:39 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v3]
In-Reply-To: <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>
Message-ID: <80R7sFyKFp0bnwiAC-fuLAcN9ZDKXB5lbTDBJ0ysL2w=.837d801f-eb4d-41d4-a4ed-99b2569e0c10@github.com>

On Mon, 30 Sep 2024 09:27:11 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
>> 
>> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
>> 
>> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
>> 
>> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
>> 
>> Testing:
>> 
>> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
>> 
>> The `ZipFileOpen` benchmark seems neutral to this change.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year for CenSizeTooLarge
>  - Delegate MAX_CEN_SIZE to existing internal constant ArraysSupport.SOFT_MAX_ARRAY_LENGTH

The latest changes in `45c9c6ef` look good to me. I haven't run our CI tests against the latest updates, so please wait for the tier1 testing to complete in GitHub actions, before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20905#pullrequestreview-2336901227

From thartmann at openjdk.org  Mon Sep 30 10:38:37 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 30 Sep 2024 10:38:37 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>

On Fri, 27 Sep 2024 14:21:57 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 three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

You've probably seen this but the new test is failing IR verification:


Failed IR Rules (4) of Methods (4)
----------------------------------
1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!

2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!

3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!

4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(MinF.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 = 1 [given]
           - No nodes matched!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2382746375

From hannesw at openjdk.org  Mon Sep 30 10:39:40 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 30 Sep 2024 10:39:40 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <QoGfFmZ-QdSDiaFJ5jl15mYke686RTSopmAuxNHTqdE=.54158994-56b6-4929-9423-17af80c1a55e@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
 <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
 <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>
 <QoGfFmZ-QdSDiaFJ5jl15mYke686RTSopmAuxNHTqdE=.54158994-56b6-4929-9423-17af80c1a55e@github.com>
Message-ID: <ssZCmv7524-RUqAivicrdzMKxZDtT_8kIAMqjQQaEgM=.7bad1a10-51e4-4c7f-bb63-b25121c5ca30@github.com>

On Mon, 30 Sep 2024 02:07:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> `<dfn>` is a semantic tag to indicate the defining instance of a term. It may be used by search engines, to improve their results.   When `<dfn>` is used as intended, it may be reasonable and convenient to put an `id` on the tag, to provide a link target for elsewhere in the documentation. It may also be convenient to add `id` to other locations, especially headers, but note that `javadoc` now does that automatically.
>> 
>> The usage of `<a name="...">` is a legacy usage from HTML 4, before the improved rules for `id` in HTML 5.  It would be a reasonable cleanup to move away from such tags, putting an equivalent `id` on either a replacement tag (such as `<span>`) or on an appropriate nearby tag.
>
> Thanks for the HTML tip; will add an id to the dfn tag.

Adding the `id` attribute to the `dfn` tag is an improvement over the `<a name=...>` tag, but the embedded `{@index ...}` tag already generates a `span` tag with a very similar id derived from the tag content, in this case `id="wrapperclasses"`. Although there may be some benefits to defining an anchor explicitly, having two very similar `id` attributes seems redundant and error-prone. My preference would be to omit the `id` from the `dfn` tag and just use the one generated by the `{@index ...}` tag in the new links.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1780841354

From lancea at openjdk.org  Mon Sep 30 10:57:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 10:57:38 GMT
Subject: RFR: 8339711: ZipFile.Source.initCEN needlessly reads END header
 [v3]
In-Reply-To: <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
 <twIJuw4PhSUrv1UfSDqScSRvjrg3pU9DbT6gvR77USc=.cba4a590-17a1-4700-8383-d884c0e8ec98@github.com>
Message-ID: <wSKdJU5I0ozqUzEE187tLUzbYiAI9pFH7aP3m24HBbU=.1305b42b-95e4-4f3a-8369-40625f1505bd@github.com>

On Mon, 30 Sep 2024 09:27:11 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
>> 
>> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
>> 
>> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
>> 
>> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
>> 
>> Testing:
>> 
>> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
>> 
>> The `ZipFileOpen` benchmark seems neutral to this change.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year for CenSizeTooLarge
>  - Delegate MAX_CEN_SIZE to existing internal constant ArraysSupport.SOFT_MAX_ARRAY_LENGTH

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20905#pullrequestreview-2337148718

From swen at openjdk.org  Mon Sep 30 11:05:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 11:05:10 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
Message-ID: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>

The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

-------------

Commit messages:
 - use loadConstant instead of ldc

Changes: https://git.openjdk.org/jdk/pull/21259/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21259&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341199
  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21259.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21259/head:pull/21259

PR: https://git.openjdk.org/jdk/pull/21259

From liach at openjdk.org  Mon Sep 30 11:19:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 11:19:37 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <f9vLZ9bVmaU3E9xL5suVH3DnUUtHkkogk33u0zFhzLw=.5ff3b6de-4791-49be-ba3f-e1302779e4f6@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

Indeed, loadConstant was invented to be more optimized than ldc. This can also avoid cp entries for small values and use 2-byte bipush or 1-byte constants, both smaller in size.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21259#pullrequestreview-2337194592

From lancea at openjdk.org  Mon Sep 30 11:26:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 11:26:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 587:

> 585:                             break;
> 586:                         case 'k':
> 587:                             kflag = true;

I am wondering if a warning should be displayed if this options is specified with any option other than 'x'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1780928849

From lancea at openjdk.org  Mon Sep 30 11:40:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 11:40:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
Message-ID: <DyVLK1xTDwn9QJ3yWozmK0pGrSgQCr15FSM3zZdKDC4=.77bec2de-aa4d-48ad-bfb2-202d63876d2d@github.com>

On Fri, 27 Sep 2024 01:42:26 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 169:
>> 
>>> 167:         extracted: {0}
>>> 168: out.kept=\
>>> 169:         \ \ skipped: {0}
>> 
>> We might want to add a bit more wording to indicate it is being skipped due to the file already existing on disk
>
> I follow existing pattern with short status update. Open to suggestions.

Perhaps something like:

` \ \  file: {0}  exists, skipped`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1780957293

From prappo at openjdk.org  Mon Sep 30 11:43:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 30 Sep 2024 11:43:35 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <ssZCmv7524-RUqAivicrdzMKxZDtT_8kIAMqjQQaEgM=.7bad1a10-51e4-4c7f-bb63-b25121c5ca30@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
 <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
 <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>
 <QoGfFmZ-QdSDiaFJ5jl15mYke686RTSopmAuxNHTqdE=.54158994-56b6-4929-9423-17af80c1a55e@github.com>
 <ssZCmv7524-RUqAivicrdzMKxZDtT_8kIAMqjQQaEgM=.7bad1a10-51e4-4c7f-bb63-b25121c5ca30@github.com>
Message-ID: <xYgjpppRyfv_zYfRPysU5qW424Ofui5gv9xlJ9XYqnk=.c616f867-4878-478f-add6-674fdf95cb48@github.com>

On Mon, 30 Sep 2024 10:36:55 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Thanks for the HTML tip; will add an id to the dfn tag.
>
> Adding the `id` attribute to the `dfn` tag is an improvement over the `<a name=...>` tag, but the embedded `{@index ...}` tag already generates a `span` tag with a very similar id derived from the tag content, in this case `id="wrapperclasses"`. Although there may be some benefits to defining an anchor explicitly, having two very similar `id` attributes seems redundant and error-prone. My preference would be to omit the `id` from the `dfn` tag and just use the one generated by the `{@index ...}` tag in the new links.

Fair enough, @hns. Initially, I thought to reply to you that we don't seem to specify the form of id generated by `@index` and that, in fact, it would be more error-prone for an author to guess/compute it in their head. For example, I would expect automatically generated ids to be camelCased.

But then I recalled the design of the `@index` tag and realised that the author does not have to think about the id. Just like index in good old paper books, javadoc index  does not discriminate between referring and the defining sites of a term. Sites are simply grouped by the term.

However, if the term is even slightly different ("wrapper class" vs "wrapper classES"), the author does not get the desired indexing without working around javadoc. Seems like `@index` might be too inflexible.

Here's a real case of bad index. Those entries are really about the same term, but that's currently inexpressible with `@index` without restructuring one of the sites:

* https://docs.oracle.com/en/java/javase/23/docs/api/java.compiler/javax/lang/model/package-summary.html#Javalanguagemodel

* https://docs.oracle.com/en/java/javase/23/docs/api/java.compiler/module-summary.html#LanguageModel

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1780960886

From sgehwolf at openjdk.org  Mon Sep 30 12:03:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 30 Sep 2024 12:03:14 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v9]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@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 34 commits:

 - 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
 - Improve systemd slice test for non-root on cg v2
 - Fix unit tests
 - Add JVM_HostActiveProcessorCount using JVM api
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - ... and 24 more: https://git.openjdk.org/jdk/compare/475b8943...92426dbf

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=08
  Stats: 1595 lines in 27 files changed: 1344 ins; 152 del; 99 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 sgehwolf at openjdk.org  Mon Sep 30 12:06:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 30 Sep 2024 12:06:41 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v9]
In-Reply-To: <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@github.com>
Message-ID: <Ss7K1vZp8uuqcTagoUy8uMa5KctgmdrXo7-g8WBiEu0=.d2e40e0b-7373-4fec-9567-14e5e0900efb@github.com>

On Mon, 30 Sep 2024 12:03:14 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 34 commits:
> 
>  - 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
>  - Improve systemd slice test for non-root on cg v2
>  - Fix unit tests
>  - Add JVM_HostActiveProcessorCount using JVM api
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/475b8943...92426dbf

Anyone? Happy to answer any questions you might have :)

Testing run on cgroups v2 with this:


Passed: containers/cgroup/CgroupSubsystemFactory.java
Passed: containers/cgroup/TestContainerized.java
Passed: containers/docker/DockerBasicTest.java
Passed: containers/docker/ShareTmpDir.java
Passed: containers/docker/TestContainerInfo.java
Passed: containers/docker/TestCPUAwareness.java
Passed: containers/docker/TestCPUSets.java
Passed: containers/docker/TestJcmd.java
Passed: containers/docker/TestJcmdWithSideCar.java
Passed: containers/docker/TestJFREvents.java
Passed: containers/docker/TestJFRNetworkEvents.java
Passed: containers/docker/TestJFRWithJMX.java
Passed: containers/docker/TestLimitsUpdating.java
Passed: containers/docker/TestMemoryAwareness.java
Passed: containers/docker/TestMemoryWithCgroupV1.java
Passed: containers/docker/TestMisc.java
Passed: containers/docker/TestPids.java
Passed: containers/systemd/SystemdMemoryAwarenessTest.java
Passed: jdk/internal/platform/cgroup/CgroupSubsystemCpuControllerTest.java
Passed: jdk/internal/platform/cgroup/CgroupSubsystemMemoryControllerTest.java
Passed: jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java
Passed: jdk/internal/platform/cgroup/CgroupV2SubsystemControllerTest.java
Passed: jdk/internal/platform/cgroup/TestCgroupMetrics.java
Passed: jdk/internal/platform/cgroup/TestCgroupSubsystemController.java
Passed: jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java
Passed: jdk/internal/platform/cgroup/TestSystemSettings.java
Passed: jdk/internal/platform/docker/TestDockerBasic.java
Passed: jdk/internal/platform/docker/TestDockerCpuMetrics.java
Passed: jdk/internal/platform/docker/TestDockerMemoryMetrics.java
Passed: jdk/internal/platform/docker/TestGetFreeSwapSpaceSize.java
Passed: jdk/internal/platform/docker/TestLimitsUpdating.java
Passed: jdk/internal/platform/docker/TestPidsLimit.java
Passed: jdk/internal/platform/docker/TestSystemMetrics.java
Passed: jdk/internal/platform/docker/TestUseContainerSupport.java
Passed: jdk/internal/platform/systemd/SystemdMemoryAwarenessTest.java
Test results: passed: 35

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2382997765

From redestad at openjdk.org  Mon Sep 30 12:28:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 30 Sep 2024 12:28:34 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <tBbHsjuE4Z_TMUaRkszl4478JZS90hn4H2GNnFa2rBY=.42e66e56-53a9-4113-824b-8e51290ae0f4@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21259#pullrequestreview-2337353537

From redestad at openjdk.org  Mon Sep 30 12:28:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 30 Sep 2024 12:28:35 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <f9vLZ9bVmaU3E9xL5suVH3DnUUtHkkogk33u0zFhzLw=.5ff3b6de-4791-49be-ba3f-e1302779e4f6@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
 <f9vLZ9bVmaU3E9xL5suVH3DnUUtHkkogk33u0zFhzLw=.5ff3b6de-4791-49be-ba3f-e1302779e4f6@github.com>
Message-ID: <Od2fgnasBEXccQHMUsO25mpv5vOntFpEOh_bjnkuwWU=.87ee9168-751b-480c-9f3f-87fb2c1a7998@github.com>

On Mon, 30 Sep 2024 11:17:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> This can also avoid cp entries for small values and use 2-byte bipush or 1-byte constants, both smaller in size.

Yikes, I was unaware `ldc` wouldn't optimize the emitted bytecode but reading through the code and docs it's pretty obvious. Still.. why?!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383044320

From swen at openjdk.org  Mon Sep 30 12:43:34 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 12:43:34 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <mSzyumWSUziXGY1Y7CL9dIMtib55cxZISGtCSHkNn_I=.93e3d585-407d-4b66-a51d-1b1adc4fdd6b@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

I think loadConstant should be renamed to ldc

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383074136

From duke at openjdk.org  Mon Sep 30 12:43:34 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 30 Sep 2024 12:43:34 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <XIJtUfcRdXYKG2omonqlFMJkZEObW4QIgqawmzz4RlY=.9a330a56-eb2b-4265-9975-ffba25015c8d@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

I was also curious about a few other seemingly "obvious" small optimizations, like loading `-1L` as `iconst_m1; i2l` and a few other things like that. Some of these depend on whether you happen to already have a constant pool entry for a value, but some (like this example) are either equivalent or better (in size) under all circumstances.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383080027

From swen at openjdk.org  Mon Sep 30 12:52:13 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 12:52:13 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v11]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <tpf2VJBW5zYicfgpJ0rU9vm3nu7PniUm0mMFdKQscj4=.2064be90-1dcc-4a0f-9eb9-a8923ebb7dc9@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use array instead of ArrayList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/3396e379..8f678b3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=09-10

  Stats: 36 lines in 2 files changed: 24 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Mon Sep 30 12:52:13 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 12:52:13 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v10]
In-Reply-To: <KAikdSOcbJvG_NRkvTxmlaqMWxVBizxgMwATVPDNJCE=.b2fdef4c-f3c8-4a19-a5bf-661f4c5759d2@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <KAikdSOcbJvG_NRkvTxmlaqMWxVBizxgMwATVPDNJCE=.b2fdef4c-f3c8-4a19-a5bf-661f4c5759d2@github.com>
Message-ID: <cZG1MVSwfkM_BWo-jlnVyZfGIUZXBv1HRH38XjFV-l0=.853fb84a-c24d-4107-aa2b-ba288221b161@github.com>

On Mon, 30 Sep 2024 06:48:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize writeBranch

The use of Lambda in the remove method in AttributeHolder was incorrect, and I fixed it by using an array instead of List for the attributes field.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21243#issuecomment-2383098204

From redestad at openjdk.org  Mon Sep 30 12:53:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 30 Sep 2024 12:53:37 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <LMZrX_YWyJXKx74TsLA5rlO7-DORnG0twHWv_mjlnko=.50f80b01-d5f3-46c3-b112-cf1e066badf6@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

I consider this a bug in the API, too. Perhaps we could assert against usage that would have been better expressed as a `loadConstant`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383102281

From hannesw at openjdk.org  Mon Sep 30 12:55:41 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 30 Sep 2024 12:55:41 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <xYgjpppRyfv_zYfRPysU5qW424Ofui5gv9xlJ9XYqnk=.c616f867-4878-478f-add6-674fdf95cb48@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
 <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
 <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>
 <QoGfFmZ-QdSDiaFJ5jl15mYke686RTSopmAuxNHTqdE=.54158994-56b6-4929-9423-17af80c1a55e@github.com>
 <ssZCmv7524-RUqAivicrdzMKxZDtT_8kIAMqjQQaEgM=.7bad1a10-51e4-4c7f-bb63-b25121c5ca30@github.com>
 <xYgjpppRyfv_zYfRPysU5qW424Ofui5gv9xlJ9XYqnk=.c616f867-4878-478f-add6-674fdf95cb48@github.com>
Message-ID: <3WJx-ABiriV2HeLV9HPUYBtxgHHe6Jsm7H02cjiEZrk=.8ec99d49-79bf-48ac-bae2-2a3eaedba676@github.com>

On Mon, 30 Sep 2024 11:41:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Adding the `id` attribute to the `dfn` tag is an improvement over the `<a name=...>` tag, but the embedded `{@index ...}` tag already generates a `span` tag with a very similar id derived from the tag content, in this case `id="wrapperclasses"`. Although there may be some benefits to defining an anchor explicitly, having two very similar `id` attributes seems redundant and error-prone. My preference would be to omit the `id` from the `dfn` tag and just use the one generated by the `{@index ...}` tag in the new links.
>
> Fair enough, @hns. Initially, I thought to reply to you that we don't seem to specify the form of id generated by `@index` and that, in fact, it would be more error-prone for an author to guess/compute it in their head. For example, I would expect automatically generated ids to be camelCased.
> 
> But then I recalled the design of the `@index` tag and realised that the author does not have to think about the id. Just like index in good old paper books, javadoc index  does not discriminate between referring and the defining sites of a term. Sites are simply grouped by the term.
> 
> However, if the term is even slightly different ("wrapper class" vs "wrapper classES"), the author does not get the desired indexing without working around javadoc. Seems like `@index` might be too inflexible.
> 
> Here's a real case of bad index. Those entries are really about the same term, but that's currently inexpressible with `@index` without restructuring one of the sites:
> 
> * https://docs.oracle.com/en/java/javase/23/docs/api/java.compiler/javax/lang/model/package-summary.html#Javalanguagemodel
> 
> * https://docs.oracle.com/en/java/javase/23/docs/api/java.compiler/module-summary.html#LanguageModel

@pavelrappo if the goal is to define a different search term/anchor, then an explicit additional `id` is certainly justified. Regarding the last example, it is ok to use the same search term on different pages/classes. It's only within one HTML page that duplicate id's are invalid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1781063866

From eirbjo at openjdk.org  Mon Sep 30 13:09:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 30 Sep 2024 13:09:40 GMT
Subject: Integrated: 8339711: ZipFile.Source.initCEN needlessly reads END
 header
In-Reply-To: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
References: <W1jVvWJa2_on01NbTzEnN1M4Wgm_MkB57JtwUxfb0eI=.f8b3a8ee-95d0-4923-a5b0-b4db4490defe@github.com>
Message-ID: <0PKoywPrBqWeiZfZ4_hVoj8JDptGPdrvDupok87SyE8=.89b068ea-34ba-44e8-8822-4ea819f3d276@github.com>

On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not include the 22-byte trailing`END` header when reading the `CEN` section of the ZIP file.
> 
> The reading of the END header was probably brought over from native code with the transition to Java in JDK 9.
> 
> In the current JDK, the END header is unused. This needlessly complicates multiple code paths accessing the array since they must account for the trailing END record when calculating the end of CEN position.
> 
> Additionally, the enforcement of the maximum CEN size limit is currently off by one. It allows the construction of a byte array of size `Integer.MAX_VALUE - 1`, but this size is not supported by OpenJDK. Instead, the maximum CEN limit should be such that is does not exceed  `Integer.MAX_VALUE - 2`.
> 
> Testing:
> 
> The `EndOfCenValidation` test is updated to test the rejection of a CEN of size `Integer.MAX_VALUE - 1` as the new minumum rejected CEN size.
> 
> The `ZipFileOpen` benchmark seems neutral to this change.

This pull request has now been integrated.

Changeset: cff420d8
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cff420d8d3cfbbb729ee47b00c8fe38e410eab1a
Stats:     19 lines in 3 files changed: 7 ins; 0 del; 12 mod

8339711: ZipFile.Source.initCEN needlessly reads END header

Reviewed-by: lancea, jpai, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20905

From duke at openjdk.org  Mon Sep 30 13:10:37 2024
From: duke at openjdk.org (sbgoog)
Date: Mon, 30 Sep 2024 13:10:37 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>
Message-ID: <Kyc8rK1TWrws1sYww4aS9dgIN71bPbISMtDaOa_QE00=.17f8d2c5-34be-4777-b9e2-4c87b7d59b93@github.com>

On Fri, 27 Sep 2024 18:46:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.
>
> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 961:
> 
>> 959:             } catch(InterruptedException e) {
>> 960:                 checkLockFile0ErrorCode(errorCode);
>> 961:                 // Don't lose the interrupt unless we throw.
> 
> Why should we lose the interrupted status if we throw a SecurityException? It doesn't look right.

I thought that if an access error is found, then that would take precedence over the interrupt, especially since it occurs before the sleep. I was more concerned with just returning false and the caller not knowing if it's false due to interrupt, or false because the file could not be locked after all retries.

Certainly the interrupt status could move before the check which may through, but I think it's less likely that the status will be checked in a catch of SecurityException.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781099312

From dfuchs at openjdk.org  Mon Sep 30 13:13:35 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Sep 2024 13:13:35 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v7]
In-Reply-To: <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>
Message-ID: <Y67KqjbBmE_vk1j6tSRomFU2lxvltFmwOUs30waZ8Bs=.324b99e4-3db7-4c28-8255-0c71f241fc2c@github.com>

On Fri, 27 Sep 2024 18:08:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert bugID update to tests

The changes that restore the original `@bug` in tests look good to me

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21096#issuecomment-2383151330

From liach at openjdk.org  Mon Sep 30 13:23:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 13:23:36 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <l1RLYDoaxBh_GN6AU2_LGrmifu7aLYA1m1-pOD6SGA4=.996b9997-27a3-42cf-ac0e-ea4ee303e334@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

I think to address these, we will leave the specification of `loadConstant` open so we can always flexibly adjust if we need. Currently javac compiles `-1L` to a `ldc2_w` which is more similar to existing ClassFile API behavior.

For `ldc`, we can remove the `ConstantDesc` version and keep the `LoadableConstantEntry` version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383179397

From mcimadamore at openjdk.org  Mon Sep 30 13:35:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 30 Sep 2024 13:35:40 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
Message-ID: <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>

On Sat, 28 Sep 2024 06:55:11 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> Sorry for being late, but I came with a new batch of weird layouts

Nice examples, thanks.

Your examples seem to work under the assumption that e.g. a sequence of padding, or a struct that contains only padding can make sense when used only as a way to provide padding. E.g. if I need a padding of 3 bytes (e.g. because you need `char` followed by `int`), your expectation seems to be all the cases below should work:

1. paddingLayout(3)
2. paddingLayout(1) + paddingLayout(2)
3. paddingLayout(2) + paddingLayout(1)
4. struct layout whose element layouts are either 1, 2 or 3
5. sequence layout of size 1, whose element layout is either 1, 2 or 3
6. union layout with field (1)

etc.

All the above are possible ways to say "only 3 bytes" of padding. That said, if we accept all these, then we'd have to specify what the rules to make sense of these layouts actually are, by coming up with abstract "reduction" rules to compute a final padding layout given some more complex layout that contains only padding. While this is possible, it strikes me as too convoluted an approach, and I'm more at ease with stricter rules on what the Linker accepts. IMHO, the rules should ban:

* sequence layout with padding element (just use padding)
* struct/union layout with only-padding fields (again, just use padding)
* consecutive padding fields (client should merge them)

When writing this, I realize the last bullet above might be problematic for jextract: jextract models unsupported types (e.g. `long double` in x64) as padding. So I wonder what happens if two fields of unsupported types are found next to each other...

> // valid (why?)
>     var struct = MemoryLayout.structLayout(JAVA_BYTE, padding1, padding2, JAVA_INT);

This strikes me as odd, and I'd expect the current PR to reject that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383201305
PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383207847

From mcimadamore at openjdk.org  Mon Sep 30 13:35:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 30 Sep 2024 13:35:40 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
 <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
Message-ID: <YPbAyHEfec4YV--hN1H6NSzCNHHl1-iuouMfKM3Ao5M=.fbda7997-6eb9-432d-9fd0-e356a913b1d2@github.com>

On Mon, 30 Sep 2024 13:30:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When writing this, I realize the last bullet above might be problematic for jextract: jextract models unsupported types (e.g. `long double` in x64) as padding. So I wonder what happens if two fields of unsupported types are found next to each other...

That said, jextract does not generate any structs with unsupported fields, or functions with unsupported types, so perhaps there's no issue there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383205673

From dfuchs at openjdk.org  Mon Sep 30 13:41:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Sep 2024 13:41:41 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
Message-ID: <fxZZ1yA6aBrXUB597Rj15ffQ0sCTW9GImpdE97sOlWw=.a5dfad55-09c4-4c9c-9632-b69127757050@github.com>

On Thu, 19 Sep 2024 17:55:13 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Track unfulfilled timeouts during UDP queries.
>   Update exceptions handling.
>   Update TCP client to use nano time source.

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 247:

> 245:                         continue;
> 246:                     }
> 247:                     AtomicLong unfulfilledServerTimeout = unfulfilledUdpTimeouts[i];

Suggestion:

                    // unfulfilledServerTimeout is always >= 0
                    AtomicLong unfulfilledServerTimeout = unfulfilledUdpTimeouts[i];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1781153536

From redestad at openjdk.org  Mon Sep 30 13:46:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 30 Sep 2024 13:46:35 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <GBoGxGdzW7Ysx2Pg3d7XgZy41p9QybKMjCVW0MjM0II=.8aaae224-0fa1-48b9-9a02-5062046eb524@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

I'm in favor of removing `ldc(ConstantDesc)`, keeping the `ldc(LoadableConstantEntry)` for advanced uses. It's easier to add something back in than to remove a mistake, and if we leave this as-is I think we'll be doomed to trip over this over and over.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383236737

From djelinski at openjdk.org  Mon Sep 30 13:49:35 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Sep 2024 13:49:35 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <Kyc8rK1TWrws1sYww4aS9dgIN71bPbISMtDaOa_QE00=.17f8d2c5-34be-4777-b9e2-4c87b7d59b93@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>
 <Kyc8rK1TWrws1sYww4aS9dgIN71bPbISMtDaOa_QE00=.17f8d2c5-34be-4777-b9e2-4c87b7d59b93@github.com>
Message-ID: <UaRm4XI6cR5HKT8FJhUz6khhq-qTRvd4-Mz0zlfLw3w=.6a3cd313-97df-4881-b482-a14c0ffd8e66@github.com>

On Mon, 30 Sep 2024 13:07:42 GMT, sbgoog <duke at openjdk.org> wrote:

>> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 961:
>> 
>>> 959:             } catch(InterruptedException e) {
>>> 960:                 checkLockFile0ErrorCode(errorCode);
>>> 961:                 // Don't lose the interrupt unless we throw.
>> 
>> Why should we lose the interrupted status if we throw a SecurityException? It doesn't look right.
>
> I thought that if an access error is found, then that would take precedence over the interrupt, especially since it occurs before the sleep. I was more concerned with just returning false and the caller not knowing if it's false due to interrupt, or false because the file could not be locked after all retries.
> 
> Certainly the interrupt status could move before the check which may through, but I think it's less likely that the status will be checked in a catch of SecurityException.

The status might not be explicitly checked, but setting the interrupted status will make sure that subsequent calls to sleep/await/tryLock etc. will not block.

In general, we want to preserve the interrupted status until either the user decides that it's fine to clear, or until the thread dies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781168496

From dfuchs at openjdk.org  Mon Sep 30 13:56:38 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Sep 2024 13:56:38 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
Message-ID: <kLjgvhBBDHc3y_MfpiQyUdqpW0MoCZlS0AbP9f0WPy4=.ec752ead-ce6e-4272-92cc-092d18118cfc@github.com>

On Thu, 19 Sep 2024 17:55:13 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Track unfulfilled timeouts during UDP queries.
>   Update exceptions handling.
>   Update TCP client to use nano time source.

This looks good to me. I believe this should lead to the least surprising behavior to the user, where we wait at least for the expected timeout.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20892#pullrequestreview-2337639659

From duke at openjdk.org  Mon Sep 30 14:07:41 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 30 Sep 2024 14:07:41 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
 <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
Message-ID: <TU6P84voA1WOKzQAOt3t77XsGiUtG9eorFtMl0e4AHE=.97e7f217-c5fe-4a60-8921-df97e539b53f@github.com>

On Mon, 30 Sep 2024 13:30:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>abstract "reduction" rules

I already use similar "reduction" in stripNames(), but not only for PaddingLayout. For example, nested structures and unions are unpacked to be flatter and the MethodHandle cache is more efficient. I like this approach.

>current PR to reject that

In its current state it doesn't seem to do this. Will you be making further changes?

---

What about my examples 3 and 4 with overaligned unions? They look like a serious problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383308269

From liach at openjdk.org  Mon Sep 30 14:09:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 14:09:36 GMT
Subject: RFR: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <mSzyumWSUziXGY1Y7CL9dIMtib55cxZISGtCSHkNn_I=.93e3d585-407d-4b66-a51d-1b1adc4fdd6b@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
 <mSzyumWSUziXGY1Y7CL9dIMtib55cxZISGtCSHkNn_I=.93e3d585-407d-4b66-a51d-1b1adc4fdd6b@github.com>
Message-ID: <sLq2BUjYLGYfgnQfMCrUKSWEsd6K9xLH30hWcQ3axsg=.71ce6939-efd6-4340-9326-5db0ebc9df6c@github.com>

On Mon, 30 Sep 2024 12:38:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.
>
> I think loadConstant should be renamed to ldc

@wenshao You can integrate this patch early even though it's much less than 24 hours. I have another patch that removes `ldc(ConstantDesc)`. It depends on your patch being integrated first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21259#issuecomment-2383313803

From dfuchs at openjdk.org  Mon Sep 30 14:09:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Sep 2024 14:09:37 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <UaRm4XI6cR5HKT8FJhUz6khhq-qTRvd4-Mz0zlfLw3w=.6a3cd313-97df-4881-b482-a14c0ffd8e66@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>
 <Kyc8rK1TWrws1sYww4aS9dgIN71bPbISMtDaOa_QE00=.17f8d2c5-34be-4777-b9e2-4c87b7d59b93@github.com>
 <UaRm4XI6cR5HKT8FJhUz6khhq-qTRvd4-Mz0zlfLw3w=.6a3cd313-97df-4881-b482-a14c0ffd8e66@github.com>
Message-ID: <WlgOJZWOBnUK2b1Cs1JlRRHKs-r0GxD3sTDtkfYW_DM=.5e632273-8b56-4d8a-8162-6d1f13df9a0d@github.com>

On Mon, 30 Sep 2024 13:46:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I thought that if an access error is found, then that would take precedence over the interrupt, especially since it occurs before the sleep. I was more concerned with just returning false and the caller not knowing if it's false due to interrupt, or false because the file could not be locked after all retries.
>> 
>> Certainly the interrupt status could move before the check which may through, but I think it's less likely that the status will be checked in a catch of SecurityException.
>
> The status might not be explicitly checked, but setting the interrupted status will make sure that subsequent calls to sleep/await/tryLock etc. will not block.
> 
> In general, we want to preserve the interrupted status until either the user decides that it's fine to clear, or until the thread dies.

In which case the code might be simplified to just:

            } catch (InterruptedException e) {
                // Don't lose the interrupt
                Thread.currentThread().interrupt();
                break;
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781202892

From duke at openjdk.org  Mon Sep 30 14:09:49 2024
From: duke at openjdk.org (Johny Jose)
Date: Mon, 30 Sep 2024 14:09:49 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b
Message-ID: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>

Timezone data 2024b changes

-------------

Commit messages:
 - 8339637: (tz) Update Timezone Data to 2024b

Changes: https://git.openjdk.org/jdk/pull/21265/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339637
  Stats: 1351 lines in 23 files changed: 393 ins; 81 del; 877 mod
  Patch: https://git.openjdk.org/jdk/pull/21265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21265/head:pull/21265

PR: https://git.openjdk.org/jdk/pull/21265

From swen at openjdk.org  Mon Sep 30 14:14:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 14:14:10 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v12]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <NiwZp4K_nHJq8QX-zr_dUb2SpVenF6WE8zOi_ZpiI60=.c6f10665-af13-47fa-9a57-0e9ef84a3d90@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - optimize setLabelTarget
 - optimize checkType
 - optimize labelBinding
 - optimize AttributeHolder::withAttribute

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/8f678b3f..d1059c58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=10-11

  Stats: 45 lines in 3 files changed: 18 ins; 17 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Mon Sep 30 14:14:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 14:14:44 GMT
Subject: Integrated: 8341199: Use ClassFile's new API loadConstant(int)
In-Reply-To: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
References: <uTRyIcwhoURM96ugYBa_12y10KJc-sbBU79L5IC5Fwc=.0d3ffe15-2a2f-4ae9-b5e3-f3b696c90fe9@github.com>
Message-ID: <75fM19KEehM7Qt1gC51S1iJB5V8VMsLOUX3CP_ZEWCg=.7ef70eec-c418-4da2-a21a-41438eae7f65@github.com>

On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The new API loadConstant(int) can shorten the calling path and can replace ldc when the parameter is of int/Integer type.

This pull request has now been integrated.

Changeset: f1bf469b
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1bf469b4ee07b48b629a126111e307d3cab7fd7
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8341199: Use ClassFile's new API loadConstant(int)

Reviewed-by: liach, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/21259

From mcimadamore at openjdk.org  Mon Sep 30 14:24:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 30 Sep 2024 14:24:35 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <TU6P84voA1WOKzQAOt3t77XsGiUtG9eorFtMl0e4AHE=.97e7f217-c5fe-4a60-8921-df97e539b53f@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
 <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
 <TU6P84voA1WOKzQAOt3t77XsGiUtG9eorFtMl0e4AHE=.97e7f217-c5fe-4a60-8921-df97e539b53f@github.com>
Message-ID: <lkdkY5-gEih8YXgezTaQRD-5nI4Bw8eaQnzdnVMiPvc=.115b0308-6f02-4018-a14f-c2a5feba4637@github.com>

On Mon, 30 Sep 2024 14:05:23 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> > abstract "reduction" rules
> 
> I already use a similar "reduction" in stripNames(), but for all layouts, not just PaddingLayout. For example, nested structures and unions are unpacked to be flatter and the MethodHandle cache is more efficient. I like this approach.

It seems something that makes sense for the implementation to do (e.g. to maximize number of cache hits). Not sure if e.g. `struct { x, y }` == `struct { struct { x } { struct y } }` in all ABIs, so probably something that the linker will want to do carefully.

It is also possible that maybe the javadoc could get away by just saying that there must be some padding, w/o really having to specify how such padding should be encoded (e.g. via a single padding layout, or multiple, or nested in a sequence). 

> 
> > current PR to reject that
> 
> In its current state it doesn't seem to do this. Will you be making further changes?

I believe we will need to make further changes based on your additional examples. E.g. we need to decide how liberal we want to be with respect to padding and then enforce that uniformly. I agree that the current patch doesn't enforce the invariants I had in mind reliably.

> 
> What about my examples 3 and 4 with overaligned unions? They look like a serious problem.

Alignment and padding is also a problem. In that you can't merge padding layouts if the alignment of the merged parts is different (which is why I was initially skeptical that we could capture all these rules in the javadoc). Realistically, the Linker should probably reject any padding layout that has alignment other than 1. As a stretch we could allow padding that is naturally aligned (e.g. padding of size 4, aligned to 4), but even that seems a bit overkill.

Also, in your union example there's another problem as well: the additional padding field is redundant, at least according to the rules in the javadoc: there's a single non-padding field with size 32 and alignment 8. I don't think anything else is needed here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383353460

From duke at openjdk.org  Mon Sep 30 14:28:39 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 30 Sep 2024 14:28:39 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <lkdkY5-gEih8YXgezTaQRD-5nI4Bw8eaQnzdnVMiPvc=.115b0308-6f02-4018-a14f-c2a5feba4637@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
 <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
 <TU6P84voA1WOKzQAOt3t77XsGiUtG9eorFtMl0e4AHE=.97e7f217-c5fe-4a60-8921-df97e539b53f@github.com>
 <lkdkY5-gEih8YXgezTaQRD-5nI4Bw8eaQnzdnVMiPvc=.115b0308-6f02-4018-a14f-c2a5feba4637@github.com>
Message-ID: <z3eNDycyXJ64Z2Dpu4x4gL2N2tnw9xuzbSrkVstey58=.c397cfdb-2ea1-4df7-ac2c-9c96fcbd63cc@github.com>

On Mon, 30 Sep 2024 14:21:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> in all ABIs

So... Ok, I did it for Android and it works. I don't know what should be in Windows or exotic Linux

And why doesn't the current stripNames remove the targets from AddressLayout for the parameters from DowncallHandle?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383365717

From duke at openjdk.org  Mon Sep 30 14:31:51 2024
From: duke at openjdk.org (sbgoog)
Date: Mon, 30 Sep 2024 14:31:51 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v2]
In-Reply-To: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
Message-ID: <4yH_PnWRTKESSIHhlF7sbxI4_d9ZGNvUvikp-yuPiY4=.1c836729-bc77-42bd-aec8-59fc4db6e4d9@github.com>

> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

sbgoog 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 one new commit since the last revision:

  8339850: Restore the interrupt status in FileSystemPreferences.lockFile()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20938/files
  - new: https://git.openjdk.org/jdk/pull/20938/files/27cba448..0b030411

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20938&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20938&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20938.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20938/head:pull/20938

PR: https://git.openjdk.org/jdk/pull/20938

From duke at openjdk.org  Mon Sep 30 14:31:52 2024
From: duke at openjdk.org (sbgoog)
Date: Mon, 30 Sep 2024 14:31:52 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v2]
In-Reply-To: <WlgOJZWOBnUK2b1Cs1JlRRHKs-r0GxD3sTDtkfYW_DM=.5e632273-8b56-4d8a-8162-6d1f13df9a0d@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>
 <Kyc8rK1TWrws1sYww4aS9dgIN71bPbISMtDaOa_QE00=.17f8d2c5-34be-4777-b9e2-4c87b7d59b93@github.com>
 <UaRm4XI6cR5HKT8FJhUz6khhq-qTRvd4-Mz0zlfLw3w=.6a3cd313-97df-4881-b482-a14c0ffd8e66@github.com>
 <WlgOJZWOBnUK2b1Cs1JlRRHKs-r0GxD3sTDtkfYW_DM=.5e632273-8b56-4d8a-8162-6d1f13df9a0d@github.com>
Message-ID: <Gg6gjnR52xZ9cDA-jHWvUR5IAGtbh9yCxSyL-t6UsI8=.06bf2e53-f5aa-4127-a787-14fa73b1d304@github.com>

On Mon, 30 Sep 2024 14:06:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The status might not be explicitly checked, but setting the interrupted status will make sure that subsequent calls to sleep/await/tryLock etc. will not block.
>> 
>> In general, we want to preserve the interrupted status until either the user decides that it's fine to clear, or until the thread dies.
>
> In which case the code might be simplified to just:
> 
>             } catch (InterruptedException e) {
>                 // Don't lose the interrupt
>                 Thread.currentThread().interrupt();
>                 break;
>             }

I've reworked the change to always set the interrupted status. I wouldn't remove the check of the error code here, as it'd be a behavior change. I can follow up with that, though it seems to me that it's good to still have the check for access error here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781250726

From mcimadamore at openjdk.org  Mon Sep 30 14:34:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 30 Sep 2024 14:34:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <ETne0S2nn3a4ss4fsRTvuOtJ4LOgw2Ya-_uPZTZ_UFc=.31fccd59-5a43-4958-8662-3e9bd8aceaff@github.com>

On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword doce

> And why doesn't the current stripNames remove the targets from AddressLayout for the parameters from DowncallHandle?

I suspect because the target layout is potentially significant in:
* return position (for downcalls)
* parameter position (for upcalls)

It is true that target layout is ignored in the dual cases of the ones above - but that's a separate issue/optimization that should not be addressed by this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383382131

From duke at openjdk.org  Mon Sep 30 14:37:38 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 30 Sep 2024 14:37:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <lkdkY5-gEih8YXgezTaQRD-5nI4Bw8eaQnzdnVMiPvc=.115b0308-6f02-4018-a14f-c2a5feba4637@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
 <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
 <TU6P84voA1WOKzQAOt3t77XsGiUtG9eorFtMl0e4AHE=.97e7f217-c5fe-4a60-8921-df97e539b53f@github.com>
 <lkdkY5-gEih8YXgezTaQRD-5nI4Bw8eaQnzdnVMiPvc=.115b0308-6f02-4018-a14f-c2a5feba4637@github.com>
Message-ID: <Tzmgs6kkwO68UpMQw-GP2zfkVh6Hh9ILbhbqK3Nz1-k=.8546f3d3-181b-43cc-874e-ce86adb3fb0a@github.com>

On Mon, 30 Sep 2024 14:21:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>I don't think anything else is needed here.

Besides the fact that it shouldn't run, but it does (all 4 examples does)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383388238

From dfuchs at openjdk.org  Mon Sep 30 14:44:35 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Sep 2024 14:44:35 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
Message-ID: <MJ2RuOPIDf2hM8n_VQUzIqcUmax2LQ3NN_TkFBcjR24=.a6279985-8d52-4787-b0f9-f0b51c11af17@github.com>

On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
> 
> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

I am not a spcialist here. But if sorting the parent list is considered as a modification, and if the sublist is just a view of the parent list, then surely sorting/modifying the sublist should be considered as a modification of the parent list? 

In which case the issue here is probably deeper: SubList and parent list appear to maintain separate `modcount` variables which are only loosely coupled. Maybe that's the bug that ought to be fixed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2383407392

From duke at openjdk.org  Mon Sep 30 14:59:12 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 30 Sep 2024 14:59:12 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v3]
In-Reply-To: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
Message-ID: <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>

> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20796/files
  - new: https://git.openjdk.org/jdk/pull/20796/files/03c0cc10..c95a0e2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20796&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20796&range=01-02

  Stats: 7 lines in 3 files changed: 1 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20796.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20796/head:pull/20796

PR: https://git.openjdk.org/jdk/pull/20796

From dfuchs at openjdk.org  Mon Sep 30 15:07:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Sep 2024 15:07:36 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v2]
In-Reply-To: <Gg6gjnR52xZ9cDA-jHWvUR5IAGtbh9yCxSyL-t6UsI8=.06bf2e53-f5aa-4127-a787-14fa73b1d304@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <Nl9gicD2XaOj_kYxv8549wfCZ3NWUjLHgzlLTdH4uVE=.aa2fb869-722b-4056-a245-5bf7add0b5aa@github.com>
 <Kyc8rK1TWrws1sYww4aS9dgIN71bPbISMtDaOa_QE00=.17f8d2c5-34be-4777-b9e2-4c87b7d59b93@github.com>
 <UaRm4XI6cR5HKT8FJhUz6khhq-qTRvd4-Mz0zlfLw3w=.6a3cd313-97df-4881-b482-a14c0ffd8e66@github.com>
 <WlgOJZWOBnUK2b1Cs1JlRRHKs-r0GxD3sTDtkfYW_DM=.5e632273-8b56-4d8a-8162-6d1f13df9a0d@github.com>
 <Gg6gjnR52xZ9cDA-jHWvUR5IAGtbh9yCxSyL-t6UsI8=.06bf2e53-f5aa-4127-a787-14fa73b1d304@github.com>
Message-ID: <LqdAK7RTPfY9NmmvDqw0YFHA1NoGtooYeIVsFfEEpSI=.133daf6a-3d5e-46f9-b6e0-b95fac6b742e@github.com>

On Mon, 30 Sep 2024 14:29:03 GMT, sbgoog <duke at openjdk.org> wrote:

>> In which case the code might be simplified to just:
>> 
>>             } catch (InterruptedException e) {
>>                 // Don't lose the interrupt
>>                 Thread.currentThread().interrupt();
>>                 break;
>>             }
>
> I've reworked the change to always set the interrupted status. I wouldn't remove the check of the error code here, as it'd be a behavior change. I can follow up with that, though it seems to me that it's good to still have the check for access error here.

My suggestion was to `break;` instead of `return false;` which would fall through to line 967 where the check method would be called. But what you have is probably preferable as it preserves the original style and keep the changes minimal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781313496

From henryjen at openjdk.org  Mon Sep 30 15:11:39 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 30 Sep 2024 15:11:39 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
Message-ID: <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>

On Mon, 30 Sep 2024 11:23:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 587:
> 
>> 585:                             break;
>> 586:                         case 'k':
>> 587:                             kflag = true;
> 
> I am wondering if a warning should be displayed if this options is specified with any option other than 'x'

I considered that, but didn't implement it after confirmed other similar options didn't display any warning.
I do think it make sense to show a warning when using an option not valid in specific mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781320078

From eosterlund at openjdk.org  Mon Sep 30 15:11:40 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 30 Sep 2024 15:11:40 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <rcGTOJcKY3ZAscPyEi3G5zKbPXRdHnJqibX5fiP4Elw=.8347be15-1ae3-4125-9f72-e230d2018a1a@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>
 <rcGTOJcKY3ZAscPyEi3G5zKbPXRdHnJqibX5fiP4Elw=.8347be15-1ae3-4125-9f72-e230d2018a1a@github.com>
Message-ID: <Lm3cvu-YkJizbmEGvRISkK4y57V46IKdGBY7INNmjD4=.70226a4a-322b-4e04-acfa-b64a16883031@github.com>

On Fri, 27 Sep 2024 18:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Is ZGC affected by this? I see only G1 and Shenandoah changes.
> 
> Good question.
> 
> ZGC expands the GC barriers late. This is why the IR test configuration that tests ZGC shows the same result as with other collectors: no additional fluff in IR. I would not expect we need anything else in late expansion for ZGC for Reference.clear, but maybe I am tired and cannot see it. Can you confirm this is fine, @fisk?

ZGC needs some changes. Without doing anything, we propagate the AS_NO_KEEPALIVE decorator to the corresponding ZBarrierNoKeepalive bit being set in the barrier data of the StorePNode. However, we don't really do anything special with that information and we will in practice end up keeping the referent alive when clearing it with generational ZGC. The point of introducing the native implementation in the first place, was to make sure our GCs don't keep the referent alive when clearing it, as the user intention is clearly to not keep it alive.

I think we need a new ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop* p) and to make that the selected slow path function when ZBarrierNoKeepalive is set on a StorePNode. Its implementation would call ZBarrier::no_keep_alive_store_barrier_on_heap_oop_field. This should do the trick.

Please let me know if you need further assistance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2383479242

From swen at openjdk.org  Mon Sep 30 15:22:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 15:22:09 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v13]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <mATO_y358-w5bbJikfAwiA65ft08OaoWHuHCMiFHUqI=.d1c50493-ca14-40ba-85a2-d1b979fdab45@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize buildContent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/d1059c58..4e1e5daf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=11-12

  Stats: 13 lines in 1 file changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From henryjen at openjdk.org  Mon Sep 30 15:24:37 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 30 Sep 2024 15:24:37 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>
Message-ID: <FhtT353ZdudsqkGwzoRXDz2rM6IdhmrCMY3N68TGsZ0=.237c203f-1d83-4211-a559-152b51ee8ff7@github.com>

On Sat, 28 Sep 2024 14:32:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks
>
> test/jdk/tools/jar/ExtractFilesTest.java line 241:
> 
>> 239:         if (rc != 0) {
>> 240:             String s = baes.toString();
>> 241:             if (s.startsWith("java.util.zip.ZipException: duplicate entry: ")) {
> 
> This method runs any arbitrary `jar` "command". Is there any significance why we are checking for a "duplicate entry" in the exception message? Maybe we could just remove this entire if block and just throw a `new IOException(s)`? As far as I can see in this test, we don't do any exception type checks on the thrown exception from this method.

I copied the method from another test that do the create jar, so it does that. Some other comments also related to copied code, I can do a round of clean up.

> test/jdk/tools/jar/MultipleManifestTest.java line 67:
> 
>> 65: 
>> 66: @TestInstance(Lifecycle.PER_CLASS)
>> 67: @TestMethodOrder(MethodName.class)
> 
> Is the use of these annotations intentional? Especially the method ordering?

I had some test failure earlier so I added those to ensure not the race condition or left over even though I don't think that's the case.
I later figured out the real cause, so I think I can remove those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781337548
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781333864

From henryjen at openjdk.org  Mon Sep 30 15:28:35 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 30 Sep 2024 15:28:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
 <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>
Message-ID: <PHcgSgtgxfAHpFOS16ibX_Z_8jcLDscDDfiM1GVnrlI=.ce3fa939-852e-40ce-87c4-2fe425660710@github.com>

On Sat, 28 Sep 2024 13:53:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Updated.
>
> Hello Henry, I think this `-k` option help text would need a slight modification. Right now it states that if a file appears more than once in an archive, then this setting this flag will not overwrite the earlier copies. In reality, it doesn't matter how many times the file appears in the archive - even if it appears just once, and if the file is being extracted into a directory which already has the same named file at that path, then this `-k` flag will not overwrite that existing file.
> 
> So I think we should reword it to talk about its behaviour in context of some file already existing in the destination directory where the jar contents are being extracted. 
> 
> I wonder if we should make a mention that we don't do any case sensitive checks for the existence of the file in the destination directory and instead we use filesystem API to check for existence (which depending on the filesystem may be case insensitive, like macosx).

You have valid point. I refer to the tar man page, and I thought do not overwrite existing files says it. The in particular is just to call out a specific use case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781344445

From lancea at openjdk.org  Mon Sep 30 15:54:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Sep 2024 15:54:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
 <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>
Message-ID: <6Rd1WefoiRuHZeJOA6PJj7NfUc-xw5J2pzFAOE-YmnQ=.7cafe564-5dbb-440c-9707-1b4887586567@github.com>

On Mon, 30 Sep 2024 15:09:21 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> I considered that, but didn't implement it after confirmed other similar options didn't display any warning. I do think it make sense to show a warning when using an option not valid in specific mode.

We do display a warning/error is some cases:  For example when we specify 'c' and 'x' we get the following message


jar cxvf foo.jar
You may not specify more than one '-cuxtid' options
Try `jar --help' for more information.


given '-k' is only relevant when used with the  '-x' option, we could specify a warning (or indicate it is ignored...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1781381620

From djelinski at openjdk.org  Mon Sep 30 16:01:38 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Sep 2024 16:01:38 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v2]
In-Reply-To: <4yH_PnWRTKESSIHhlF7sbxI4_d9ZGNvUvikp-yuPiY4=.1c836729-bc77-42bd-aec8-59fc4db6e4d9@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <4yH_PnWRTKESSIHhlF7sbxI4_d9ZGNvUvikp-yuPiY4=.1c836729-bc77-42bd-aec8-59fc4db6e4d9@github.com>
Message-ID: <aJKOBP4nFc1E5zPjX9jUlL9Ui_7kQl_AR5HYJxC5mJ8=.2f28e340-8159-418f-9470-1d1118129664@github.com>

On Mon, 30 Sep 2024 14:31:51 GMT, sbgoog <duke at openjdk.org> wrote:

>> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.
>
> sbgoog 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 one new commit since the last revision:
> 
>   8339850: Restore the interrupt status in FileSystemPreferences.lockFile()

For future reference, as the bot says, don't force push. The bot will squash all commits before merging.

The change looks good to me. Please update the copyright year.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20938#issuecomment-2383594566

From mcimadamore at openjdk.org  Mon Sep 30 16:06:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 30 Sep 2024 16:06:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <Tzmgs6kkwO68UpMQw-GP2zfkVh6Hh9ILbhbqK3Nz1-k=.8546f3d3-181b-43cc-874e-ce86adb3fb0a@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <Q1nNNQPxgQc8FjEtBTuzfvDZFfrjSYaE5x2HKXvKN8s=.2c3e1195-4b8b-4217-af3e-4a7d7020b26b@github.com>
 <tYRVk8eBKDjcN1t_kH-FXRjbyIyo3irYt3tFPq7LAis=.b9f980c1-ab46-4b12-b6dd-d096437ee702@github.com>
 <TU6P84voA1WOKzQAOt3t77XsGiUtG9eorFtMl0e4AHE=.97e7f217-c5fe-4a60-8921-df97e539b53f@github.com>
 <lkdkY5-gEih8YXgezTaQRD-5nI4Bw8eaQnzdnVMiPvc=.115b0308-6f02-4018-a14f-c2a5feba4637@github.com>
 <Tzmgs6kkwO68UpMQw-GP2zfkVh6Hh9ILbhbqK3Nz1-k=.8546f3d3-181b-43cc-874e-ce86adb3fb0a@github.com>
Message-ID: <vkNkWxsqszoZLwb5ay73QaYKTY0Lx9_1UwB2NEQ6niI=.a5712625-631d-49ab-bfee-25b014b3b9f3@github.com>

On Mon, 30 Sep 2024 14:34:49 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> > I don't think anything else is needed here.
> 
> Besides the fact that it shouldn't run, but it does (all 4 examples run without any exception!)

I meant - no other layout is needed - as we don't have any "alignment gap" here - the union size is already a multiple of its alignment. So, this seems another case where there's "redundant" padding that is not detected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383605851

From liach at openjdk.org  Mon Sep 30 16:07:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 16:07:37 GMT
Subject: RFR: 8341100: Add index entries for terms used in java.lang.Class
 [v2]
In-Reply-To: <_D7zdd9cOGvZE98jKER4JQPBgri86KzeEJZT8Y-t83Y=.a344bc78-3fd7-4f9d-8e21-3416412df2d3@github.com>
References: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
 <_D7zdd9cOGvZE98jKER4JQPBgri86KzeEJZT8Y-t83Y=.a344bc78-3fd7-4f9d-8e21-3416412df2d3@github.com>
Message-ID: <2Rdvg8wPL94d75vRq9CPjo4WA6Z-4-CL7NrKvtmnksI=.ab28b4e5-133c-4324-a2e7-24fa0d84266c@github.com>

On Mon, 30 Sep 2024 02:18:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Small update to java.lang.Class docs.
>> 
>> I didn't add an index item for "hidden classes" since the indexing mechanism picks up the section titles.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Thakns for this cleanup!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21241#pullrequestreview-2338003789

From duke at openjdk.org  Mon Sep 30 16:11:14 2024
From: duke at openjdk.org (sbgoog)
Date: Mon, 30 Sep 2024 16:11:14 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v3]
In-Reply-To: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
Message-ID: <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>

> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

sbgoog 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/20938/files
  - new: https://git.openjdk.org/jdk/pull/20938/files/0b030411..2c0c1896

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20938&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20938&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20938.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20938/head:pull/20938

PR: https://git.openjdk.org/jdk/pull/20938

From duke at openjdk.org  Mon Sep 30 16:11:14 2024
From: duke at openjdk.org (sbgoog)
Date: Mon, 30 Sep 2024 16:11:14 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v2]
In-Reply-To: <aJKOBP4nFc1E5zPjX9jUlL9Ui_7kQl_AR5HYJxC5mJ8=.2f28e340-8159-418f-9470-1d1118129664@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <4yH_PnWRTKESSIHhlF7sbxI4_d9ZGNvUvikp-yuPiY4=.1c836729-bc77-42bd-aec8-59fc4db6e4d9@github.com>
 <aJKOBP4nFc1E5zPjX9jUlL9Ui_7kQl_AR5HYJxC5mJ8=.2f28e340-8159-418f-9470-1d1118129664@github.com>
Message-ID: <8IQyHTy5SL_b9vQDXYf9gvlO31-doFC4xs_qvgPgKLk=.2f0e6513-f211-4f78-8938-67ee92414f1f@github.com>

On Mon, 30 Sep 2024 15:58:53 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> For future reference, as the bot says, don't force push. The bot will squash all commits before merging.

I didn't realize before pushing, but now I know. Thanks!

> The change looks good to me. Please update the copyright year.

I've done that now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20938#issuecomment-2383615364

From darcy at openjdk.org  Mon Sep 30 16:12:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 16:12:40 GMT
Subject: Integrated: 8341100: Add index entries for terms used in
 java.lang.Class
In-Reply-To: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
References: <mfXAX9Ku029Iw0YVDyO3Qj9rCM3eVD0-qTLammCIq1c=.43f4388e-404b-4678-88df-f31c957a779a@github.com>
Message-ID: <eb1NHGCp1u4Z1EhGgyLvuVMoDF9i-a-6bthNyQli5Lo=.20ce842e-1959-446b-a1c2-9130ca29520a@github.com>

On Sat, 28 Sep 2024 14:56:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small update to java.lang.Class docs.
> 
> I didn't add an index item for "hidden classes" since the indexing mechanism picks up the section titles.

This pull request has now been integrated.

Changeset: 4168faf5
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4168faf54c0558a7cff4ef6ac643bbbfdea0cec3
Stats:     9 lines in 1 file changed: 2 ins; 1 del; 6 mod

8341100: Add index entries for terms used in java.lang.Class

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21241

From darcy at openjdk.org  Mon Sep 30 16:16:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 16:16:41 GMT
Subject: RFR: 8341064: Define anchor point and index term for
 "wrapper classes" [v3]
In-Reply-To: <3WJx-ABiriV2HeLV9HPUYBtxgHHe6Jsm7H02cjiEZrk=.8ec99d49-79bf-48ac-bae2-2a3eaedba676@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
 <yyHAKkL0_M3mEV2Df3PA_igWxwpN3ejRz7RB-rXj7VM=.ed88d388-dfee-456f-878d-362255f21b2b@github.com>
 <KDZamiaW7CyBYrgCsqWHCj6hr6pNcBNGjshGESAaLBM=.b87b20f5-23f2-458b-a239-b91b480eedc0@github.com>
 <Da9JCXLbjOKSBxJrnZs9sKcrjRnwxQ8Z-03M5Qx1CWA=.cf7b38c1-d3c6-4f36-b63e-11a6fc814cb7@github.com>
 <kgsc3uapp6ak5c2SPI0GugaT73HgBY6l8rGy6nrEwz8=.7fc2dd7b-694b-42ee-bc74-88b6bf970d70@github.com>
 <QoGfFmZ-QdSDiaFJ5jl15mYke686RTSopmAuxNHTqdE=.54158994-56b6-4929-9423-17af80c1a55e@github.com>
 <ssZCmv7524-RUqAivicrdzMKxZDtT_8kIAMqjQQaEgM=.7bad1a10-51e4-4c7f-bb63-b25121c5ca30@github.com>
 <xYgjpppRyfv_zYfRPysU5qW424Ofui5gv9xlJ9XYqnk=.c616f867-4878-478f-add6-674fdf95cb48@github.com>
 <3WJx-ABiriV2HeLV9HPUYBtxgHHe6Jsm7H02cjiEZrk=.8ec99d49-79bf-48ac-bae2-2a3eaedba676@github.com>
Message-ID: <FJ2LhrQjedj5gAolwVGotG8r4ua4Q-Cpwr-6S8Cgis8=.db0b9ed6-a7d2-4482-9159-b8a294931eb4@github.com>

On Mon, 30 Sep 2024 12:53:26 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Fair enough, @hns. Initially, I thought to reply to you that we don't seem to specify the form of id generated by `@index` and that, in fact, it would be more error-prone for an author to guess/compute it in their head. For example, I would expect automatically generated ids to be camelCased.
>> 
>> But then I recalled the design of the `@index` tag and realised that the author does not have to think about the id. Just like index in good old paper books, javadoc index  does not discriminate between referring and the defining sites of a term. Sites are simply grouped by the term.
>> 
>> However, if the term is even slightly different ("wrapper class" vs "wrapper classES"), the author does not get the desired indexing without working around javadoc. Seems like `@index` might be too inflexible.
>> 
>> Here's a real case of bad index. Those entries are really about the same term, but that's currently inexpressible with `@index` without restructuring one of the sites:
>> 
>> * https://docs.oracle.com/en/java/javase/23/docs/api/java.compiler/javax/lang/model/package-summary.html#Javalanguagemodel
>> 
>> * https://docs.oracle.com/en/java/javase/23/docs/api/java.compiler/module-summary.html#LanguageModel
>
> @pavelrappo if the goal is to define a different search term/anchor, then an explicit additional `id` is certainly justified. Regarding the last example, it is ok to use the same search term on different pages/classes. It's only within one HTML page that duplicate id's are invalid.

I'm going to push this PR as-is. Any cleanup in index terms and `id`s can happen in a subsequent changeset. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21215#discussion_r1781412401

From darcy at openjdk.org  Mon Sep 30 16:16:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Sep 2024 16:16:41 GMT
Subject: Integrated: 8341064: Define anchor point and index term for
 "wrapper classes"
In-Reply-To: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
References: <oqOFKLuwwJpvnOd4AbEj0zGL4q7JmT1GOmIHor76Nlg=.16200b2a-0247-478e-bfc0-12a3a275e140@github.com>
Message-ID: <pp5uLlDLpxouGIm-E6_-P4lvE4Hjil5hQ5MNjZMTa9Q=.d0621e64-9924-49d2-a162-3af848262fd6@github.com>

On Thu, 26 Sep 2024 23:46:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The is the initial version of a PR to defined an anchor point and index term of "wrapper classes."

This pull request has now been integrated.

Changeset: 5586f83e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5586f83e34c2fe0bdc48daef8c456678cea55af1
Stats:     67 lines in 10 files changed: 11 ins; 0 del; 56 mod

8341064: Define anchor point and index term for "wrapper classes"

Reviewed-by: prappo, liach

-------------

PR: https://git.openjdk.org/jdk/pull/21215

From syan at openjdk.org  Mon Sep 30 16:17:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 30 Sep 2024 16:17:06 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied
Message-ID: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>

Hi all,
Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
So this PR add `readlink` permission to make this test work normally.
Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.

-------------

Commit messages:
 - 8341246: Test com/sun/tools/attach/PermissionTest.java fails access denied

Changes: https://git.openjdk.org/jdk/pull/21269/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341246
  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21269/head:pull/21269

PR: https://git.openjdk.org/jdk/pull/21269

From shade at openjdk.org  Mon Sep 30 16:36:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 16:36:20 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v4]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <836Da9CyLC9qQtoFe9YVHau-ftjmXFr87Xw2wy2DIxc=.19870ac5-3c52-4632-8093-ea47938642de@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [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 eight additional commits since the last revision:

 - Attempt at implementing ZGC AArch64 parts
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Amend the test case for guaranteing it works under different compilation regimes
 - More precise barriers
 - Tests work
 - More touchups
 - Fixing the conditions, fixing the tests
 - Crude prototype, still failing the tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/437f2329..cba0a8e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=02-03

  Stats: 258786 lines in 3084 files changed: 211178 ins; 30411 del; 17197 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

PR: https://git.openjdk.org/jdk/pull/20139

From shade at openjdk.org  Mon Sep 30 16:36:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 16:36:20 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <Lm3cvu-YkJizbmEGvRISkK4y57V46IKdGBY7INNmjD4=.70226a4a-322b-4e04-acfa-b64a16883031@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>
 <rcGTOJcKY3ZAscPyEi3G5zKbPXRdHnJqibX5fiP4Elw=.8347be15-1ae3-4125-9f72-e230d2018a1a@github.com>
 <Lm3cvu-YkJizbmEGvRISkK4y57V46IKdGBY7INNmjD4=.70226a4a-322b-4e04-acfa-b64a16883031@github.com>
Message-ID: <ixtfOfUmd7Qvf1icAGdzNWdP4rA_CAeIOnHT5X4OWIU=.7bdfd24b-f7aa-462b-ae65-6fda54dec9dd@github.com>

On Mon, 30 Sep 2024 15:08:53 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> I think we need a new ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop* p) and to make that the selected slow path function when ZBarrierNoKeepalive is set on a StorePNode. Its implementation would call ZBarrier::no_keep_alive_store_barrier_on_heap_oop_field. This should do the trick.

Thanks! See new commits: is that the shape you were thinking of? Once we get AArch64 parts right, I'll copy-paste that to other arches.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2383669579

From shade at openjdk.org  Mon Sep 30 16:50:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 16:50:13 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v5]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <4wz9wweAYNZCLw5c5fpldlEBgVyCh9io9iUih_hFVKM=.2d4a7679-0652-4f2c-8304-99bd84367519@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Fix other arches
 - Tighten up comments in Reference javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/cba0a8e9..8ba681a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=03-04

  Stats: 16 lines in 4 files changed: 7 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

PR: https://git.openjdk.org/jdk/pull/20139

From shade at openjdk.org  Mon Sep 30 16:50:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 16:50:13 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <lzbKsjK3JtjBSgMhnNnb_IMEHd86sJV0sPtRbWk5BN8=.60cc23a8-e846-481b-979f-8cd3ba4e18e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <lzbKsjK3JtjBSgMhnNnb_IMEHd86sJV0sPtRbWk5BN8=.60cc23a8-e846-481b-979f-8cd3ba4e18e7@github.com>
Message-ID: <PcfEO_LHkIlj3oFG1BjI5AgWhUzbRkFUxYDXhmFa1jU=.8059fe1e-c120-4d0f-96ba-27438aa2217a@github.com>

On Fri, 27 Sep 2024 23:51: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:
>> 
>>   Amend the test case for guaranteing it works under different compilation regimes
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 420:
> 
>> 418:     /* Implementation of clear(), also used by enqueue().  A simple
>> 419:      * assignment of the referent field won't do for some garbage
>> 420:      * collectors.
> 
> Description of clear0 is rendered stale by this change.  The first sentence is no longer true, since it's now
> clearImpl that has that role.  The second sentence probably ought to also be moved into the description of
> clearImpl.

Thanks! I tightened up comments a bit, take another look?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1781452602

From shade at openjdk.org  Mon Sep 30 16:59:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 16:59:16 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Also dispatch to slow-path on other arches

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/8ba681a4..4fe4a911

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=04-05

  Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

PR: https://git.openjdk.org/jdk/pull/20139

From jvernee at openjdk.org  Mon Sep 30 17:07:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 30 Sep 2024 17:07:46 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <3EiusEynJophkZit60FyWA03NXWVjgAoCwNlJfeTh7o=.17f73dc6-3ed9-4b9e-8748-265cd25d5ac5@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>
 <BPXpziMnJ5abo68eNo6ClJH2c-eTDmJbT0ul71h_ysk=.0397a5ca-505e-469c-a6de-0574e6d58fe4@github.com>
 <3EiusEynJophkZit60FyWA03NXWVjgAoCwNlJfeTh7o=.17f73dc6-3ed9-4b9e-8748-265cd25d5ac5@github.com>
Message-ID: <8FTxHRmKPQ35BTBG8Kvq9Tn_2J6acpi9zdnt89U94-4=.750c3348-19de-460e-96c6-9b8f8f00d0f4@github.com>

On Sun, 29 Sep 2024 23:52:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `form` field is a final field; thus, all reads to that field is a load-acquire. This load-load barrier is critical to ensure observing the correct, non-null `vmentry` field value if the updated form is observed.
>> 
>> Note that JIT compilation may constant-fold the preexisting form and ignore the updated form. This is still behaviorally identical, but usually the new form is more suitable for constant folding if JIT compilation can pick it up.
>
> That's not exactly how final fields are specified. It is hard to see here exactly what fields/objects are involved in this case. The final field semantics only provide load-acquire-like semantics if you dereference the final field after the freeze action in the constructor. And our use of Unsafe here means we are stepping outside any JLS guarantees anyway.

In this case there is no classic release/acquire. Instead, we rely on other properties: The `vmentry` field is loaded in `MethodHandles::jump_to_lambda_form`, using a plain load. I believe a load-acquire is not needed here because we have a data dependency: we load the `vmentry` field from `form`, and the initialization of the `vmentry` field takes place before the new value of `form` is published. This, combined with the guarantee that a newly allocated object will always have to be freshly loaded after its publication, means that if a thread sees the new `form` field value, it will also see the new `vmentry` field in the subsequent load. (This is also why safe publication works AFAIK)

> A full-fence is a one-sided global synchronization action.

FWIW, a full fence is just a release+acquire on the executing thread. It has no effect on other threads. All the fences in `Unsafe` are one-sided synchronization actions. (The only exception I know of is what is done by `SystemMemoryBarrier` in hotspot)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1781477862

From eirbjo at openjdk.org  Mon Sep 30 19:14:45 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 30 Sep 2024 19:14:45 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
Message-ID: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>

Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.

This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.

My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 

Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).

I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.

Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.

Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.

Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

-------------

Commit messages:
 - Add @modules jtreg tag to XcodeOverflow test, required to use ArraysSupport.SOFT_MAX_ARRAY_LENGTH
 - Consolidate and use ArraysSupport.SOFT_MAX_ARRAY_LENGTH in place of Integer.MAX_VALUE - 8

Changes: https://git.openjdk.org/jdk/pull/21268/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341243
  Stats: 64 lines in 15 files changed: 23 ins; 9 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/21268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21268/head:pull/21268

PR: https://git.openjdk.org/jdk/pull/21268

From attila at openjdk.org  Mon Sep 30 19:46:34 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 30 Sep 2024 19:46:34 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <aIxX6fMnCtQ9eQqUU1Ou32J1J_MgQ5gZUyej0PcRP5M=.fbbeab52-4033-405f-851b-13b0431cdbcc@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
 <aIxX6fMnCtQ9eQqUU1Ou32J1J_MgQ5gZUyej0PcRP5M=.fbbeab52-4033-405f-851b-13b0431cdbcc@github.com>
Message-ID: <B56h2M-9ARx7sZZvfRdJ3Luu5hNCt-U2_DKMmisTcuk=.0d40b2f2-cb84-43f2-af41-1446e3b0b594@github.com>

On Sun, 29 Sep 2024 21:50:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
>> 
>> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.
>
> Just an observation, but sorting is not defined as a "structural modification" but obviously would interfere with an active iterator. So the docs may need updating to include this aspect.

@dholmes-ora and @dfuch both your observations are quite valid and I agree with them. If you look at the [JBS issue](https://bugs.openjdk.org/browse/JDK-8340572), we discussed this topic there. 

Clarifying the collections' behavior with regard to when to throw a CME, and hopefully making that behavior be consistent would be a welcome enhancement. As things stand, the scope of this fix is just ensuring that the behavior of ArrayList reverts back to what it was prior to my optimization, since the change triggered a test failure in some Google test suite. All the while recognizing that the behavior was not particularly consistent to begin with.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2384017097

From msheppar at openjdk.org  Mon Sep 30 20:33:36 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 30 Sep 2024 20:33:36 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
Message-ID: <uk0JI1cKrg6jWecOzS6Ysmk-4GJ_nI8dcInmd5cxhqU=.cc6865cd-46a4-4ab1-a52c-0e2eaa8acade@github.com>

On Thu, 19 Sep 2024 17:55:13 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Track unfulfilled timeouts during UDP queries.
>   Update exceptions handling.
>   Update TCP client to use nano time source.

I think that if there is a PortUnreachable thrown, during DnsClient.query processing from the doUdpQuery, then  the  timeout may expire early ... if I've interpreted the outer loop processing correctly

I'm surprised that we haven't encountered this more frequently, BUT it may have a occurred as there were a couple of failures where timeout was quite minimal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2384091460

From sviswanathan at openjdk.org  Mon Sep 30 21:02:42 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 30 Sep 2024 21:02:42 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
Message-ID: <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>

On Tue, 24 Sep 2024 07:10:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2698:

> 2696:   int cast_vopc = VectorCastNode::opcode(-1, elem_bt, true);
> 2697:   if (is_floating_point_type(elem_bt)) {
> 2698:     index_elem_bt = elem_bt == T_FLOAT ? T_INT : T_LONG;

index_elem_bt is already assigned at line 2676 and 2678 so this line could be removed.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 551:

> 549:         return ((ByteVector)src1).vectorFactory(res);
> 550:     }
> 551: 

This could instead be:
   src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);
Or even simplified to:
   src1.rearrange(this.toShuffle(), src2);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1777839817
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1779722306

From swen at openjdk.org  Mon Sep 30 21:14:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Sep 2024 21:14:50 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v14]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <69FVbTkjZz1rAog3wm8HBFpO5JxX5rRC8zqlPFmwSoQ=.902af368-b37e-4c65-a605-4ad75927a563@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - optimize MethodTypeDescImpl::descriptorString
 - Remove redundant requireNonNull

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/4e1e5daf..77174a2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=12-13

  Stats: 30 lines in 3 files changed: 17 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From psandoz at openjdk.org  Mon Sep 30 21:30:42 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 30 Sep 2024 21:30:42 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
Message-ID: <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>

On Sat, 28 Sep 2024 17:37:10 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 551:
> 
>> 549:         return ((ByteVector)src1).vectorFactory(res);
>> 550:     }
>> 551: 
> 
> This could instead be:
>    src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);
> Or even simplified to:
>    src1.rearrange(this.toShuffle(), src2);

I think you have to do the masking before conversion - `vec.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle()` is not the same as `vec.toShuffle()` for all inputs.


jshell> IntVector indexes = IntVector.fromArray(IntVector.SPECIES_256, new int[] {0, 1, 8, 9, 16, 17, 24, 25}, 0);
indexes ==> [0, 1, 8, 9, 16, 17, 24, 25]

jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1)
$19 ==> [0, 1, 8, 9, 0, 1, 8, 9]

jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1).toShuffle()
$20 ==> Shuffle[0, 1, -8, -7, 0, 1, -8, -7]

jshell> indexes.toShuffle()
$21 ==> Shuffle[0, 1, -8, -7, -8, -7, -8, -7]

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781753872

From sviswanathan at openjdk.org  Mon Sep 30 22:42:41 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 30 Sep 2024 22:42:41 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
Message-ID: <xvYwWzD25AlVkJ2f9mbTGybDborygUYSOHhIHgu07jw=.f6955795-f5dd-46a4-86f2-7ac0aa2cff22@github.com>

On Tue, 24 Sep 2024 07:10:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.

src/hotspot/cpu/x86/x86.ad line 10490:

> 10488: %{
> 10489:   match(Set index (SelectFromTwoVector (Binary index src1) src2));
> 10490:   effect(TEMP index);

Just curious, why do we need TEMP index effect?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781742786

From sviswanathan at openjdk.org  Mon Sep 30 22:42:42 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 30 Sep 2024 22:42:42 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
Message-ID: <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>

On Mon, 30 Sep 2024 21:28:22 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 551:
>> 
>>> 549:         return ((ByteVector)src1).vectorFactory(res);
>>> 550:     }
>>> 551: 
>> 
>> This could instead be:
>>    src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);
>> Or even simplified to:
>>    src1.rearrange(this.toShuffle(), src2);
>
> I think you have to do the masking before conversion - `vec.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle()` is not the same as `vec.toShuffle()` for all inputs.
> 
> 
> jshell> IntVector indexes = IntVector.fromArray(IntVector.SPECIES_256, new int[] {0, 1, 8, 9, 16, 17, 24, 25}, 0);
> indexes ==> [0, 1, 8, 9, 16, 17, 24, 25]
> 
> jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1)
> $19 ==> [0, 1, 8, 9, 0, 1, 8, 9]
> 
> jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1).toShuffle()
> $20 ==> Shuffle[0, 1, -8, -7, 0, 1, -8, -7]
> 
> jshell> indexes.toShuffle()
> $21 ==> Shuffle[0, 1, -8, -7, -8, -7, -8, -7]

Thanks for the example. Yes, you have a point there.  So we would need to do:
   src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781859166

From bpb at openjdk.org  Mon Sep 30 23:11:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Sep 2024 23:11:41 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <cE6IQ71zuBvo79X18ra-2yeUXOTRlZW01GNk-7Ug1xc=.4bad2079-570f-4c55-903f-f2615a9a2c89@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <cE6IQ71zuBvo79X18ra-2yeUXOTRlZW01GNk-7Ug1xc=.4bad2079-570f-4c55-903f-f2615a9a2c89@github.com>
Message-ID: <O1zviSQKtHT0g2GclphNTUq9iE0jicibl6-Jchk_FHo=.78aa3cf1-c3bb-49a4-97f8-d6729cc032c1@github.com>

On Sun, 29 Sep 2024 07:00:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."
>
> src/java.base/share/classes/java/io/FileInputStream.java line 166:
> 
>> 164:     /**
>> 165:      * Creates a {@code FileInputStream} to read from an existing file
>> 166:      * represented by the {@code FileDescriptor} object {@code fdObj}.
> 
> I don't know if you meant to touch this constructor or not but I think it's okay to use "connected" here as this is creating a FIS to read bytes from whatever the file descriptor is connected to.

I have reverted it locally and that will be in the next commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1781881827

From liach at openjdk.org  Mon Sep 30 23:11:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 23:11:42 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v14]
In-Reply-To: <69FVbTkjZz1rAog3wm8HBFpO5JxX5rRC8zqlPFmwSoQ=.902af368-b37e-4c65-a605-4ad75927a563@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <69FVbTkjZz1rAog3wm8HBFpO5JxX5rRC8zqlPFmwSoQ=.902af368-b37e-4c65-a605-4ad75927a563@github.com>
Message-ID: <p9oqJbDhXuVGEbh085XKmt49NqVIy05NRESgR0Gx_sc=.11d9ad06-cfa9-4885-8c73-3895b80abc95@github.com>

On Mon, 30 Sep 2024 21:14:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - optimize MethodTypeDescImpl::descriptorString
>  - Remove redundant requireNonNull

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 103:

> 101:     @Override
> 102:     public <T extends PoolEntry> T entryByIndex(int index, Class<T> cls) {
> 103:         Objects.requireNonNull(cls);

I think this was added because we want the NPE to be thrown before IAE if index is 0 but cls is null. It might be fine one way or another.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1781881645

From bpb at openjdk.org  Mon Sep 30 23:16:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Sep 2024 23:16:34 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
Message-ID: <yAKIIJjTwQsnnhzKTcA08FpCKvLp3tRP8mMvc1sYQ3I=.37d57641-760c-4ea7-95a0-3c7447d721a7@github.com>

On Sat, 28 Sep 2024 06:49:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."
>
> src/java.base/share/classes/java/io/FileInputStream.java line 118:
> 
>> 116:     /**
>> 117:      * Creates a {@code FileInputStream} to read from an existing file
>> 118:      * named by the {@code File} object {@code file}.
> 
> Hello Brian, should be perhaps reword this as "... to read from an existing file represented by the {@code file}." This would almost match what we state for the constructor which takes the `FileDescriptor` instance.

Updated for the next commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1781891337

From sviswanathan at openjdk.org  Mon Sep 30 23:17:43 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 30 Sep 2024 23:17:43 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
Message-ID: <c_TaCEW9UtukTGyJUq1SDjU5Pztv5M8VBRszYuyCmzY=.75e9959d-aeed-412f-9203-b72df804fe3e@github.com>

On Tue, 24 Sep 2024 07:10:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2689:

> 2687:         !arch_supports_vector(cast_vopc, num_elem, T_BYTE, VecMaskNotUsed)                   ||
> 2688:         !arch_supports_vector(Op_VectorLoadShuffle, num_elem, index_elem_bt, VecMaskNotUsed) ||
> 2689:         !arch_supports_vector(Op_Replicate, num_elem, T_BYTE, VecMaskNotUsed)) {

Where SelectFromTwoVector is not supported, the alternate implementation is as part of SelectFromTwoVectorNode::Ideal() instead of right here.  A comment both here as well as in the Ideal() implementation is needed to keep these checks in sync.

src/hotspot/share/opto/vectornode.cpp line 2120:

> 2118:   // are held in a byte vector which are later transformed to target specific permutation
> 2119:   // index format by subsequent VectorLoadShuffle.
> 2120:   int cast_vopc = VectorCastNode::opcode(0, index_elem_bt, true);

Good to use -1 when we are not sending an actual opcode:
int cast_vopc = VectorCastNode::opcode(-1, index_elem_bt, true);

src/hotspot/share/opto/vectornode.cpp line 2126:

> 2124:   Node* bcast_lane_cnt_m1_vec = phase->transform(VectorNode::scalar2vector(lane_cnt_m1, num_elem, Type::get_const_basic_type(T_BYTE), false));
> 2125: 
> 2126:   // Compute the blend mask for merging two indipendently permututed vectors

Typo indipendently -> independently

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781867326
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781873682
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781888912

From sviswanathan at openjdk.org  Mon Sep 30 23:17:43 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 30 Sep 2024 23:17:43 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <c_TaCEW9UtukTGyJUq1SDjU5Pztv5M8VBRszYuyCmzY=.75e9959d-aeed-412f-9203-b72df804fe3e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <c_TaCEW9UtukTGyJUq1SDjU5Pztv5M8VBRszYuyCmzY=.75e9959d-aeed-412f-9203-b72df804fe3e@github.com>
Message-ID: <6NYy2NcP98xm3QRYdBWaAkkrvTdquMhhWnm-svxQjwE=.955f6dc8-c74c-472b-8c32-10228bb68d99@github.com>

On Mon, 30 Sep 2024 22:51:57 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2689:
> 
>> 2687:         !arch_supports_vector(cast_vopc, num_elem, T_BYTE, VecMaskNotUsed)                   ||
>> 2688:         !arch_supports_vector(Op_VectorLoadShuffle, num_elem, index_elem_bt, VecMaskNotUsed) ||
>> 2689:         !arch_supports_vector(Op_Replicate, num_elem, T_BYTE, VecMaskNotUsed)) {
> 
> Where SelectFromTwoVector is not supported, the alternate implementation is as part of SelectFromTwoVectorNode::Ideal() instead of right here.  A comment both here as well as in the Ideal() implementation is needed to keep these checks in sync.

We need to add VectorMaskCast here in the checks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1781886783

From bpb at openjdk.org  Mon Sep 30 23:19:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Sep 2024 23:19:34 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
Message-ID: <TgwXDwGagCMDMxxqFMnXKxBjT8-N-oFy3KTDyXg39eU=.d0880863-ed68-493e-b048-0b4d35952b7e@github.com>

On Sat, 28 Sep 2024 06:51:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Do you think, as part of this PR, we should also revisit some of the javadoc in the `java.io.FileOutputStream` class which too has several mentions of "connection"?

Are you thinking of this sentence 

```A new FileDescriptor object is created to represent this file connection.```

which appears for the four constructors which do not have a `FileDescriptor` parameter? Those four sentences could probably be deleted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21223#issuecomment-2384373790

From liach at openjdk.org  Mon Sep 30 23:42:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Sep 2024 23:42:06 GMT
Subject: RFR: 8341277: Validate slot argument for instruction factories
Message-ID: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>

Perform validation of local variable slots, multinewarray dimension, iinc value and specify these validations are performed. Specify these exception behaviors for sipush and bipush as well.

This validation avoids using invalid values that will be lost once class files are written, and avoids invalid value pollution from upstream in chained transformations.

This changes the exception specs of Class-File API, but does not block the JEP as it does not change the intended functionality of these APIs.

Unfortunately, I cannot test the DirectCodeBuilder overloads due to it failing to generate stack maps, so the tests are restricted to instruction factories.

-------------

Commit messages:
 - slot and some other validation

Changes: https://git.openjdk.org/jdk/pull/21275/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341277
  Stats: 417 lines in 15 files changed: 337 ins; 51 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/21275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21275/head:pull/21275

PR: https://git.openjdk.org/jdk/pull/21275